Quels types de certificats puis-je signer moi-même ? (Et devrais-je vraiment le faire ?)

Imaginez que vous fassiez partie de l'équipe d'ingénieurs de l'Étoile de la mort (I). Il y a un problème à résoudre : il n'y a aucun moyen d'évacuer la chaleur générée par l'énorme moteur interne sans construire un port d'échappement directement dans l'espace.

"Personne ne trouvera cette petite faille", pensez-vous. "Il est impossible qu'un Jedi intrépide arrive à bord d'un X-wing et détruise tout ce que j'ai mis tant d'efforts à construire." 

Imaginez maintenant que vous fassiez partie de l'équipe d'ingénieurs de l'Étoile de la mort (II). La première chose à faire ? Régler le problème de l'orifice d'échappement dès le départ, très probablement, ainsi que toute autre vulnérabilité de la surface d'attaque susceptible de mettre en péril le réacteur central, l'infrastructure critique sur laquelle reposent toutes les ambitions de l'empire. 

Lorsqu'il s'agit de PKI dans votre organisation, le port d'échappement défectueux est une simple erreur de configuration ou un défaut de conception, comme un certificat auto-signé qui ne passe pas les tests.

Dans de nombreux cas, les certificats auto-signés peuvent sembler être l'option la plus pratique, mais ils deviennent rapidement une menace pour la sécurité lorsqu'ils sont mal gérés ou, pire, déployés dans des environnements de production. 

Not only do self-signed certificates lack the validation offered by Certificate Authorities (CAs), but improper certificate management practices leave security gaps when combined with other elements of poor PKI hygiene, such as lax key storage.

Au lieu de laisser les certificats auto-signés à la portée des acteurs malveillants, tirez parti d'une solution automatisée et centralisée de gestion du cycle de vie des certificats pour minimiser les risques et protéger votre organisation. 

Certificats que vous pouvez signer vous-même

In certain situations, self-signed certificates serve a useful purpose within an organization’s infrastructure: they offer a quick, cost-effective way to support SSL/TLS functionality without requiring CA infrastructure. Proceed with caution, however; these self signed certificates should be limited to very specific, codified internal uses to avoid the security risks associated with unvalidated / unvalidated certificates. 

Environnements de développement et de test

Les certificats auto-signés permettent aux développeurs dans les environnements de test de simuler la fonctionnalité SSL/TLS rapidement et sans frais, permettant aux équipes de tester les connexions sécurisées et le cryptage sans impliquer une autorité de certification. Ces environnements doivent être isolés des réseaux publics et ne contenir que des données de test assainies, ce qui réduit la nécessité de maintenir une chaîne de confiance publique ou la chaîne de confiance privée de votre organisation. Le hic, c'est qu'il est toujours essentiel de maintenir l'autorité et le contrôle sur ces types de certificats afin d'éviter leur migration accidentelle dans les environnements de production. 

Services et réseaux internes

Pour certains outils internes, sites intranet et applications dont l'accès est strictement réservé aux utilisateurs autorisés, les certificats auto-signés peuvent également être acceptés. Dans un environnement contrôlé où les utilisateurs et les appareils externes ne peuvent pas accéder aux ressources internes, l'absence de signature d'une autorité de certification fiable n'a qu'un impact minime. Cependant, même pour un usage interne, les certificats auto-signés doivent être gérés avec soin ; l'expiration du certificat ou l'exposition par inadvertance au public sont toujours des problèmes potentiels. Toutefois, il est toujours recommandé d'utiliser un certificat privé interne PKI plutôt qu'un certificat auto-signé si cela est possible.

Solutions à court terme ou temporaires

Lorsqu'un certificat est nécessaire pour un projet à court terme ou une application de durée limitée, l'auto-signature peut être l'option la plus simple. Lorsqu'un projet est utilisé en interne ou en privé pendant une période brève et spécifique, les certificats auto-signés offrent un moyen rapide d'établir des connexions sécurisées. Comme pour chacun des exemples précédents, ces types de certificats doivent toujours être soumis à des pratiques de gestion du cycle de vie des certificats afin de les mettre hors service en toute sécurité lorsqu'ils n'ont plus d'utilité.

As with many elements of cybersecurity (generally) and PKI (specifically), the use of self-signed certificates in your organization fall under risk management. With the right authority and maintenance, self-signed certificates can be a fast, handy solution; without a comprehensive CLM, these handy certs can quickly turn a useful tool into a devastating weakness. 

Certificats que vous ne devez PAS autosigner

Most certificates should not be self-signed. Low risk is not the same as no risk; self-signed certificates fail to meet compliance standards, often are poorly minted with extensions asserted, are easy for bad actors to spoof, and cannot be trusted in many environments due to the fluid nature of most enterprise networks trying to get a new certificate pushed to all the trust stores.

Dans le cas des applications publiques, des services orientés clients, de la signature de code et des environnements de production, les certificats émis par une autorité de certification de confiance sont essentiels à la sécurité, à la confiance et à une expérience utilisateur harmonieuse. 

Sites web publics (SSL/TLS certificats)

On the internet, certificates from publicly trusted CAs are critical for secure, verifiable connections. Browsers and other clients do not recognize self-signed certificates as legitimate, greeting visitors with warnings that the site connection is “not secure.” These warnings erode user trust, detract from user experience, and discourage users from engaging with the website for their own protection. More importantly, self-signed certificates on public sites create an opportunity for in man-in-the-middle attacks, in which malicious actors intercept and manipulate data sent between the website and its visitors.

Recommendation: It’s a best practice to use CA-issued SSL/TLS certificates for public websites to protect against impersonation and maintain user confidence in your site (and, by extension, your brand). These types of certificates have short expiration windows; with a centralized CLM, you can automate the issuance, renewal, and revocation processes to save time and prevent human error.

Applications et services destinés aux clients

Any application or service that interacts with clients or external users should use publicly trusted certificates. When client applications, browsers, or APIs communicate over HTTPS or other secure protocols, self-signed certificates trigger security warnings if they’re not rejected outright. This disruption of connectivity impacts trust, with clients perceiving the service as insecure or unprofessional. Moreover, if a self-signed certificate is used and bypassed in these settings, user data may be at risk from potential attackers who could exploit the lack of trusted verification. 

Recommendation: Certificates issued by a trusted CA protect your clients from insecurity warnings and enable a consistent, secure connection to the apps and services they need. 

Certificats de signature de code

Ces certificats valident l'authenticité de software et vérifient qu'il n'a pas été modifié depuis qu'il a été signé, indiquant la transition de l'environnement "test" à l'environnement "production". La plupart des systèmes d'exploitation et des magasins d'applications n'acceptent pas les codes auto-signés, car ils ne garantissent pas l'identité du développeur. À l'instar des navigateurs, si un certificat auto-signé est utilisé pour signer le code, les utilisateurs sont susceptibles de recevoir des avertissements indiquant que le site software provient d'une source non fiable, ce qui suscite des hésitations et des problèmes de sécurité potentiels. 

Recommendation: Use CA-issued signing certificates to avoid security alerts and facilitate smooth installations, maintaining user trust in the software. 

Environnements de production

The goal of development and testing is to get to the production environment, in which your application, software, or service is externally exposed. Production demands a high level of reliability, visibility, and security; even test environments that connect to production resources often need to establish an elevated level of trust to reduce security risks. Using self-signed certificates in production—or testing environments that mirror production—introduces unnecessary vulnerability, increasing the risk of operational disruptions if certificates expire or become compromised. 

Recommendation: Use authoritative, CA-issued certificates for production environments such as the corporate trusted PKI for internal use cases or a publicly trust CA for external user access use cases.. A trusted CA should offer scalable solutions that provide these types of certificates on demand, effectively eliminating the barrier of issuing CA-signed certs for internal resources. For added security, use trusted certificates wherever possible.

Éliminer le besoin de certificats auto-signés avec PKIaaS

Self-signed certificates might offer a quick fix for small teams or low-risk internal applications, but as your organization scales and digital operations grow more complex, they become a liability – introducing vulnerabilities and creating management headaches.

Avec Keyfactor's PKI-as-a-Service, vous pouvez éliminer complètement le besoin de certificats auto-signés. L'automatisation et la gestion centralisée des certificats simplifient l'émission, le suivi de l'expiration et le renouvellement de tous vos actifs numériques. Le résultat ? Une solution PKI efficace, évolutive et sécurisée qui évolue avec votre organisation.

Ne nous croyez pas sur parole : Keyfactor a obtenu la première place dans le rapport Frost Radar™ 2024 pour la croissance et l'innovation parmi les fournisseurs de PKIaaS. Les équipes de sécurité qui font face à une pression croissante pour protéger les systèmes critiques se tournent vers Keyfactor pour une approche " cloud-first " qui fournit PKI à la demande.

Close the exhaust port and secure your Death Star – err, organization – with professionally managed PKI infrastructure that leaves nothing to chance. Build user trust, protect your systems, and stay ahead of tomorrow’s challenges with Keyfactor.

Les prochaines étapes 

Curious to know more? We’re here to help! You can request a demo to brainstorm with our team, get your questions answered, and discover which solution best fits your needs.