Suis-je en train de manquer quelque chose? Est-ce la bonne façon de créer un certificat auto-signé?
Il est facile de créer un certificat auto-signé. Vous utilisez simplement la openssl reqcommande. Il peut être difficile d'en créer un qui peut être consommé par la plus grande sélection de clients, comme les navigateurs et les outils de ligne de commande.
C'est difficile car les navigateurs ont leur propre ensemble d'exigences, et ils sont plus restrictifs que l' IETF . Les exigences utilisées par les navigateurs sont documentées sur les forums CA / Browser (voir les références ci-dessous). Les restrictions se posent dans deux domaines clés: (1) les ancres de confiance et (2) les noms DNS.
Les navigateurs modernes (comme le warez que nous utilisons en 2014/2015) veulent un certificat qui renvoie à une ancre de confiance, et ils veulent que les noms DNS soient présentés de manière particulière dans le certificat. Et les navigateurs évoluent activement contre les certificats de serveur auto-signés.
Certains navigateurs ne facilitent pas exactement l'importation d'un certificat de serveur auto-signé. En fait, vous ne pouvez pas avec certains navigateurs, comme le navigateur d'Android. La solution complète est donc de devenir votre propre autorité.
En l'absence de devenir votre propre autorité, vous devez obtenir les bons noms DNS pour donner au certificat les meilleures chances de succès. Mais je vous encourage à devenir votre propre autorité. Il est facile de devenir votre propre autorité, et cela évitera tous les problèmes de confiance (à qui mieux faire confiance que vous?).
Ce n'est probablement pas le site que vous recherchez!
Le certificat de sécurité du site n'est pas fiable!
En effet, les navigateurs utilisent une liste prédéfinie d'ancres de confiance pour valider les certificats de serveur. Un certificat auto-signé ne renvoie pas à une ancre approuvée.
La meilleure façon d'éviter cela est:
- Créez votre propre autorité (c.-à-d. Devenez CA )
- Créer une demande de signature de certificat (CSR) pour le serveur
- Signez la CSR du serveur avec votre clé CA
- Installer le certificat de serveur sur le serveur
- Installer le certificat CA sur le client
Étape 1 - Créer votre propre autorité signifie simplement créer un certificat auto-signé avec CA: trueune utilisation appropriée des clés. Cela signifie que le sujet et l' émetteur sont la même entité, CA est défini sur true dans les contraintes de base (il doit également être marqué comme critique), l'utilisation de la clé est keyCertSignet crlSign(si vous utilisez des listes de révocation de certificats) et l' identificateur de la clé du sujet (SKI) est Identique à l' identifiant de clé d'autorité (AKI).
Pour devenir votre propre autorité de certification, voir * Comment signez-vous une demande de signature de certificat avec votre autorité de certification? sur Stack Overflow. Ensuite, importez votre autorité de certification dans le Trust Store utilisé par le navigateur.
Les étapes 2 à 4 correspondent à peu près à ce que vous faites maintenant pour un serveur public lorsque vous vous inscrivez aux services d'une autorité de certification comme Startcom ou CAcert . Les étapes 1 et 5 vous permettent d'éviter l'autorité tierce et d'agir comme votre propre autorité (à qui faire confiance mieux que vous?).
La deuxième meilleure façon d'éviter l'avertissement du navigateur est de faire confiance au certificat du serveur. Mais certains navigateurs, comme le navigateur par défaut d'Android, ne vous permettent pas de le faire. Cela ne fonctionnera donc jamais sur la plate-forme.
Le problème des navigateurs (et autres agents utilisateurs similaires) qui ne font pas confiance aux certificats auto-signés va être un gros problème dans l'Internet des objets (IoT). Par exemple, que va-t-il se passer lorsque vous vous connectez à votre thermostat ou réfrigérateur pour le programmer? La réponse est, rien de bon en ce qui concerne l'expérience utilisateur.
Le groupe de travail WebAppSec du W3C commence à examiner la question. Voir, par exemple, Proposition: Marquer HTTP comme non sécurisé .
Comment créer un certificat auto-signé avec OpenSSL
Les commandes ci-dessous et le fichier de configuration créent un certificat auto-signé (il vous montre également comment créer une demande de signature). Ils diffèrent des autres réponses sur un point: les noms DNS utilisés pour le certificat auto-signé se trouvent dans le nom alternatif du sujet (SAN) et non dans le nom commun (CN) .
Les noms DNS sont placés dans le SAN via le fichier de configuration avec la ligne subjectAltName = @alternate_names(il n'y a aucun moyen de le faire via la ligne de commande). Ensuite, il y a une alternate_namessection dans le fichier de configuration (vous devez régler cela à votre goût):
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# IP.1 = 127.0.0.1
# IP.2 = ::1
Il est important de mettre le nom DNS dans le SAN et non le CN, car à la fois l'IETF et le CA / Forums du navigateur précisent la pratique. Ils précisent également que les noms DNS dans le CN sont obsolètes (mais pas interdits). Si vous mettez un nom DNS dans le CN, il doit être inclus dans le SAN sous les stratégies CA / B. Vous ne pouvez donc pas éviter d'utiliser l'autre nom du sujet.
Si vous ne placez pas de noms DNS dans le SAN, le certificat ne pourra pas être validé sous un navigateur et d'autres agents utilisateurs qui suivent les directives de CA / Browser Forum.
Connexes: les navigateurs suivent les politiques de CA / Browser Forum; et non les politiques de l'IETF. C'est l'une des raisons pour lesquelles un certificat créé avec OpenSSL (qui suit généralement l'IETF) ne valide parfois pas sous un navigateur (les navigateurs suivent le CA / B). Ce sont des normes différentes, elles ont des politiques d'émission différentes et des exigences de validation différentes.
Créez un certificat auto-signé (notez l'ajout d'une -x509option):
openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
-keyout example-com.key.pem -days 365 -out example-com.cert.pem
Créez une demande de signature (notez le manque d' -x509option):
openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \
-keyout example-com.key.pem -days 365 -out example-com.req.pem
Imprimez un certificat auto-signé :
openssl x509 -in example-com.cert.pem -text -noout
Imprimer une demande de signature :
openssl req -in example-com.req.pem -text -noout
Fichier de configuration (transmis via -configoption)
[ req ]
default_bits = 2048
default_keyfile = server-key.pem
distinguished_name = subject
req_extensions = req_ext
x509_extensions = x509_ext
string_mask = utf8only
# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
# Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = NY
localityName = Locality Name (eg, city)
localityName_default = New York
organizationName = Organization Name (eg, company)
organizationName_default = Example, LLC
# Use a friendly name here because it's presented to the user. The server's DNS
# names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
# by both IETF and CA/Browser Forums. If you place a DNS name here, then you
# must include the DNS name in the SAN too (otherwise, Chrome and others that
# strictly follow the CA/Browser Baseline Requirements will fail).
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Example Company
emailAddress = Email Address
emailAddress_default = test@example.com
# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
# You only need digitalSignature below. *If* you don't allow
# RSA Key transport (i.e., you use ephemeral cipher suites), then
# omit keyEncipherment because that's key transport.
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# In either case, you probably only need serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# In either case, you probably only need serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# DNS.7 = 127.0.0.1
# IPv6 localhost
# DNS.8 = ::1
Vous devrez peut-être effectuer les opérations suivantes pour Chrome. Sinon, Chrome peut se plaindre qu'un nom commun n'est pas valide ( ERR_CERT_COMMON_NAME_INVALID) . Je ne sais pas quelle est la relation entre une adresse IP dans le SAN et un CN dans ce cas.
# IPv4 localhost
# IP.1 = 127.0.0.1
# IPv6 localhost
# IP.2 = ::1
Il existe d'autres règles concernant la gestion des noms DNS dans les certificats X.509 / PKIX. Reportez-vous à ces documents pour les règles:
Les RFC 6797 et RFC 7469 sont répertoriées, car elles sont plus restrictives que les autres RFC et documents CA / B. Les RFC 6797 et 7469 ne permettent pas non plus une adresse IP.