web-dev-qa-db-fra.com

Impossible de charger les certificats lors de la tentative de génération de fichier pfx

Je lutte depuis trois heures pour essayer de créer un fichier .pfx en utilisant OpenSSL. J'ai suivi ce document et j'ai suivi les instructions sous l'en-tête Get a certificate using OpenSSL.

Je suis à l'étape ici: openssl pkcs12 -export -out myserver.pfx -inkey myserver.key -in myserver.crt et j'utilise la console OpenSSL.exe.

J'ai l'erreur: unable to load certificates

J'ai aussi essayé ceci: x509 -text -in myserver.key et j'ai reçu l'erreur: 0906D06D06C:PEM_read_bio:no start line:.\crypto\pem\pem_lib.b.c:703:Expecting: TRUSTED CERTIFICATE Je reçois aussi cette erreur si j'essaie myserver.crt.

Je semble l'obtenir, peu importe ce que je fais.

Puis-je avoir une aide s'il vous plait?

sslopenssl
14
davy

J'ai l'erreur: impossible de charger les certificats

myserver.crt doit être au format PEM. At-il ----- BEGIN CERTIFICATE ----- et ----- END CERTIFICATE -----?

myserver.crt devrait en réalité être une chaîne de certificats (et pas seulement le certificat d'un serveur). La chaîne doit inclure tous les certificats intermédiaires nécessaires au client pour vérifier la chaîne.

Vous envoyez tous les certificats intermédiaires pour résoudre le problème "quel répertoire". Le "quel répertoire" est un problème bien connu dans PKI. Essentiellement, le client ne sait pas où aller pour récupérer le certificat intermédiaire manquant. Pour éviter le problème, vous envoyez tous les intermédiaires.

J'utilise souvent Startcom car ils offrent des certificats gratuits de classe 1. Lorsque j'obtiens le certificat de serveur signé d'eux (par exemple, www-example-com.crt), j'y ajoute leur serveur intermédiaire de classe 1. Je reçois leur serveur intermédiaire de classe 1 sur leur site Web à l’adresse Startcom CA certs . Celui que j'utilise est sub.class1.server.ca.pem.

Avec le www-example-com.crt, mon certificat de serveur ressemble à:

$ cat www-example-com.crt

-----BEGIN CERTIFICATE-----
< My Server Certificate >
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
< Startcom Intermediate >
-----END CERTIFICATE-----

Pour être complet, la clé privée (par exemple, www-example-com.key) est également au format PEM. Il utilise -----BEGIN RSA PRIVATE KEY----- et -----END RSA PRIVATE KEY-----.

Avec mon certificat de serveur au format PEM (et avec les intermédiaires requis) et ma clé privée, je publie ensuite le texte suivant (qui ressemble à la même commande que vous utilisez):

openssl pkcs12 -export -in www-example-com.crt -inkey www-example-com.key -out www-example-com.p12

Lorsque les clients se connectent, ils utilisent l’autorité de certification Startcom. Donc, pour tester la connexion (après le chargement dans IIS):

openssl s_client -connect www.example.com:443 -CAfile startcom-ca.pem

La commande devrait se terminer par "Verify OK":

SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 37E5AF0EE1745AB2...
    Session-ID-ctx:
    Master-Key: 7B9F8A79D3CC3A41...
    Key-Arg   : None
    Start Time: 1243051912
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

J'ai aussi essayé ceci: x509 -text -in myserver.key et j'ai reçu l'erreur ...

x509 est pour les certificats. Si vous souhaitez sauvegarder une clé, utilisez la commande pkey d'OpenSSL. Voir la documentation sur la commande pkey(1) d'OpenSSL.

11
jww

J'ai suivi ce document ...

En passant, d'après la documentation citée :

Les certificats de base sont des certificats dont le nom commun (CN) du fichier Le certificat est défini sur le domaine ou le sous-domaine spécifique que les clients utilisera pour visiter le site. Par exemple, www.contoso.com. Celles-ci les certificats ne sécurisent que le nom de domaine unique spécifié par le CN.

Il existe deux normes pour ce genre de choses. Le premier concerne les RFC et le second les exigences de CA-Browser (CA/B). Les RFC sont générales parce qu’elles s’appliquent à un grand nombre de protocoles et de services différents et qu’elles couvrent un large réseau pour couvrir de nombreuses pratiques {existantes} _. À cause de cela, les RFC sont un peu bâclées - elles permettent beaucoup de choses contre-intuitives. Par exemple, regardez la variable keyUsage admissible de RFC 5280 dans la section 4.2.1.3.

Les CA et les navigateurs se sont réunis et ont formé les forums CA/B. Ensemble, ils publient des normes qu'ils suivent. Les pratiques de CA/B sont un peu plus disciplinées (vous pourriez le considérer comme un sous-ensemble des RFC). Si vous examinez leurs Exigences de base , vous constaterez que CN est obsolète et ne doit pas être utilisé. Si une CN est utilisée, le même nom doit figurer dans une SAN:

9.2.2 Champ Nom commun du sujet

Champ de certificat: sujet: commonName (OID 2.5.4.3)

Obligatoire/Facultatif: Obsolète (Déconseillé, mais non interdit)

Contenu: S'il est présent, ce champ DOIT contenir une seule adresse IP ou Nom de domaine complet qui correspond à l'une des valeurs contenues dans le fichier SubjectAltName du certificat (voir la section 9.2.1).

La ligne du bas: vous devriez éviter de mettre un nom d’hôte ou un nom de domaine dans la variable CN. Vous l'évitez parce que c'est ce que l'autorité de certification a accepté de faire et c'est ce à quoi les navigateurs s'attendent. (Et si vous n'accédez pas au site via un navigateur, faites ce que vous voulez).

Les deux normes spécifient avec humour l’utilisation du nom de domaine complet. Les noms de domaine complets sont des noms qui se terminent par un point ".". Je n'ai pas encore vu de certificat bien formé selon l'une ou l'autre des normes.

1
jww