Erreur SSL - impossible de lire le certificat de serveur à partir d'un fichier


37

J'ai mis en place SSL pour mon domaine aujourd'hui et j'ai trouvé un autre problème: j'espérais que quelqu'un pourrait nous éclairer un peu.

Je continue à recevoir les messages d'erreur suivants:

[erreur] Init: Impossible de lire le certificat de serveur à partir du fichier /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt
[erreur] Erreur de bibliothèque SSL: erreur 218529960: 0D0680A8: routines de codage asn1: ASN1_CHECK_TLEN: balise incorrecte
[erreur] Erreur de bibliothèque SSL: erreur 218595386: 0D07803A: routines de codage asn1: ASN1_ITEM_EX_D2I: erreur asn1 imbriquée

J'utilise Apache 2.2.16 et Ubuntu 10.10. Mon fichier .crt a les balises Begin et End, et a été copié exactement de l'email de confirmation que j'ai reçu, très frustrant!

À votre santé!

Éditer >> En essayant de vérifier le fichier .crt Cela ne semble pas fonctionner:

>> openssl x509 -noout -text -in domain.com.crt 
impossible de charger le certificat
16851: erreur: 0906D06C: routines PEM: PEM_read_bio: aucune ligne de départ: pem_lib.c: 650: attente: CERTIFICAT DE CONFIANCE

Aussi >>

>> openssl x509 -text -inform PEM -in domaine.com.crt
impossible de charger le certificat
21321: erreur: 0906D06C: routines PEM: PEM_read_bio: aucune ligne de départ: pem_lib.c: 650: attente: CERTIFICAT DE CONFIANCE
>> openssl x509 -text -inform DER -in domaine.com.crt
impossible de charger le certificat
21325: erreur: 0D0680A8: routines de codage asn1: ASN1_CHECK_TLEN: balise incorrecte: tasn_dec.c: 1316:
21325: erreur: 0D07803A: routines de codage asn1: ASN1_ITEM_EX_D2I: erreur asn imbriquée: tasn_dec.c: 380: type = X509

Edit >> (Acclamations pour l'aide en passant)

>> grep '^ -----' domaine.com.crt
----- COMMENCER CERTIFICAT -----
----- CERTIFICAT FINAL -----

Il suffit d'envoyer un e-mail à l'entreprise fournissant le certificat, ils ont répondu>

J'ai vérifié le fichier CSR que vous avez fourni et je peux vous assurer qu'il a été généré correctement. L'erreur que vous rencontrez actuellement est due au fait que vous utilisez une mauvaise ligne de commande pour installer la CSR. Vous devrez modifier ce domain.com.crt à partir de votre ligne de commande avec le nom correspondant à votre domaine.

  • actuellement, le crt est configuré sur mysite.com.crt - j'ai utilisé domain.com.crt comme exemple

Pourriez-vous s'il vous plaît nous montrer la sortie de grep '^-----' domain.com.crt?
quanta

Williamsowen, le certificat doit être présenté à toute personne se connectant à votre serveur Web. ce n'est pas une chose privée. Cela dit, envisageriez-vous de joindre ou d'afficher l'intégralité du certificat ici afin que nous puissions l'examiner directement au lieu de devoir deviner?
MadHatter soutient Monica le

Attendez, je vois que vous venez d'accepter ma réponse. Cela signifie-t-il que des problèmes d’alimentation de ligne Windows étaient à l’origine du problème?
MadHatter soutient Monica le

MadHatter - excuses! Nouveau pour cela, mais je viens juste de le faire fonctionner, le formatage de l'email que j'ai reçu était désactivé, je ne pouvais pas vous remercier assez les gars!
williamsowen

Réponses:


49

Est-il possible que les lignes soient terminées par ^ M? Il s'agit d'un problème potentiel lors du déplacement de fichiers de Windows vers des systèmes UNIX. Un moyen simple de vérifier consiste à utiliser le mode vi"Montre-moi le binaire" avec vi -b /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt.

Si chaque ligne se termine par un control-M, comme ceci

-----BEGIN CERTIFICATE-----^M
MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM^M
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg^M
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x^M

vous avez un fichier au format Windows avec terminaison de ligne et Apache n'aime pas ceux-ci.

Vos options incluent le déplacement du fichier à nouveau, en prenant plus de précautions; ou en utilisant la dos2unixcommande pour les dépouiller; vous pouvez également les supprimer à l'intérieur de vi, si vous êtes prudent.


Edit : merci à @ dave_thompson_085, qui a signalé que cette réponse ne s'appliquait plus en 2019. En d’autres termes, Apache / OpenSSL sont maintenant tolérants envers les lignes ^ M terminées, ils ne causent donc pas de problèmes. Cela dit, d'autres erreurs de mise en forme, dont plusieurs exemples différents apparaissent dans les commentaires, peuvent toujours poser problème. vérifiez attentivement si le certificat a été déplacé d'un système à l'autre.


Pour moi, c’était une erreur de copier / coller en omettant les deux premiers caractères de l’en-tête -----BE... Merci de nous avoir inspiré pour vérifier!
cfi

Merci, c'était mon problème! Dans Notepad ++, dans Windows, vous pouvez utiliser la boîte de dialogue de conversion EDIT-EOL pour modifier le format correct du BF. Et vous pouvez également utiliser le menu View-Show Symbol pour voir les fins de ligne Windows CR LF.
Bjørn

1
Mon certificat a simplement fini par être un fichier vide. Quelque chose s'est cassé dans la génération je suppose. Cette réponse m'a encouragé à l'ouvrir et à voir cela.
Flickerfly

Remarque pour les utilisateurs Windows: Vous devrez probablement convertir le format de ligne en UNIX, même si vous utilisez Windows. DOS2UNIX n'est pas une commande Windows, mais une commande Linux. La bonne nouvelle, Git pour Windows le fournit. CigWin en a probablement aussi, mais je n'en suis pas sûr.
Ignacio Segura

Remarque pour les utilisateurs Windows: une liste d'autorisations dans l'onglet Propriétés / Sécurité de l'Explorateur Windows est perturbée après la copie d'un fichier d'autorisations restreintes à partir d'un partage réseau avec le cp de Cygwin. Par exemple, j'ai vu un "NUL SID", une entrée désactivée de Tout le monde et d'utilisateurs de domaine.
anguille ghEEz

19

Pour toute personne arrivant sur cette page avec une erreur similaire lors de la tentative de lecture d'une demande de signature de certificat (CSR) (notez que OP lit un certificat): veillez à utiliser la bonne commande OpenSSL. x509est pour les certificats et reqest pour les CSR:

openssl req -in server.csr -text -noout

contre

openssl x509 -in server.crt -text -noout

17

Je me suis contenté de tourner en rond, et il s’est avéré que j’avais les certificats en sens inverse - par exemple

SSLCertificateFile    /etc/apache2/ssl/server.key
SSLCertificateKeyFile /etc/apache2/ssl/server.crt

au lieu de:

SSLCertificateFile    /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key

Quelque chose à vérifier si vous obtenez cette erreur.


11
>> openssl x509 -noout -text -in domain.com.crt 
unable to load certificate
16851:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:650:Expecting: TRUSTED CERTIFICATE

Je soupçonne que vous avez un problème avec le format du certificat.

Exécutez les deux commandes suivantes et donnez-nous la sortie:

openssl x509 -text -inform DER -in domain.com.crt 
openssl x509 -text -inform PEM -in domain.com.crt 

Merci pour cette réponse. J'ai été en mesure de déterminer le format fourni par mes SA en tant que ".cer" était déjà ".pem" incognito
javafueled le

10

Dans mon cas, j'ai trouvé que mon certificat avait différents caractères "-". Il doit s'agir d'un problème de copier / coller de l'administrateur qui a placé le certificat sur le serveur, l'éditeur de texte étant remplacé par un caractère unicode spécial.

Cela a pris des heures pour diagnostiquer, et à la fin je l'ai juste deviné, et j'ai édité le certificat dans vi et supprimé les caractères "-" existants, puis les retapés.

J'espère que ça aide quelqu'un.


8

Dans mon cas, j'ai rencontré les erreurs de l'OP parce que celui qui a créé le fichier .crt pour moi à l'origine avait réellement créé un fichier au format .PEM et l'a nommé .crt.

J'ai découvert cela en rencontrant le guide utile suivant: https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how -à-convertir-les

tout ce que je devais faire était de renommer mon .crt en un .pem, et j'avais terminé! Le guide indiquait que les erreurs de la question de l'OP impliquent que le fichier d'entrée est déjà au format PEM. Il est donc impossible d'essayer de le convertir au format .pem à partir d'un format DER, qui est en fait inutile.


4

Assurez-vous que votre fichier ne contient aucun espace de fin ni de début dans le fichier de certificat. Assurez-vous soigneusement qu'il n'y a aucun espace ni espace dans votre fichier de certificat en sélectionnant le texte entier et en recherchant des espaces dans un éditeur de texte uniquement.

Vérifiez également si tous les fichiers configurés existent et sont corrects.

Exemple: dans votre autre message, vous dites que votre fichier .key s'appelle my domain.com.crt alors que sur la configuration vhost, vous avez domain.com.crt.

SSLCertificateFile /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt
SSLCertificateKeyFile /etc/apache2/domain.ssl/domain.ssl.key/domain.com.key
SSLCertificateChainFile /etc/apache2/domain.ssl/ca.crt
SSLCACertificateFile /etc/apache2/domain.ssl/gs_intermediate_ca.crt

Vérifiez à nouveau que tous les fichiers ci-dessus existent vraiment et sont valides.


1
Vérifiez également que vos tirets sont des tirets. Les éditeurs de texte Microsoftiens aiment se changer --en ; ce n'était pas très amusant à résoudre.
Shane Madden

Oui, puisque vous êtes sur Ubuntu, ouvrez simplement un terminal et utilisez nano par exemple. De cette façon, vous serez sûr.
George Tasioulis le

Bonjour, merci pour vos commentaires - j'ai tout vérifié et tout va bien. J'ai essayé de vérifier le fichier CRT mais je reçois:sudo openssl x509 -noout -text -in domain.com.crt unable to load certificate 16851:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:650:Expecting: TRUSTED CERTIFICATE
williamsowen le

1
La première ligne de votre fichier domain.com.crt commence-t-elle -----BEGIN CERTIFICATE-----et la dernière ligne se termine- -----END CERTIFICATE-----t-elle?
George Tasioulis le

1

Si quelqu'un d'autre rencontre ce problème et que vos journaux d'erreurs Apache disent quelque chose comme:

Init: impossible de lire le certificat de serveur à partir du fichier /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt

Assurez-vous que vous n'avez pas échangé vos fichiers de clé et de certificat dans les déclarations de la configuration d'Apache. J'avais pointé la clé sur mon fichier de certificat et le certificat sur mon fichier de clé. Cet article m'a aidé à comprendre le problème, mais je voulais le signaler comme un autre problème / solution potentiel.


0

Mon problème (ayant la même erreur lors de l'installation d'un nouveau serveur avec Apache 2.4) était qu'Apache (2.4) ne pouvait pas lire le fichier binaire .crt. Je l'ai importé dans mon magasin de certificats personnel (avec mmc) et l'ai exporté au format X.509 (.cer) codé en base 64. Renommé le fichier exporté avec le même nom (.crt) (utilisé dans mon httpd-ssl.conf) et cela a fonctionné à nouveau! Le même certificat a fonctionné sur mon ancien serveur, peut-être Apache 2.4 est-il plus strict que 2.2? Bonne chance.


0

Dans mon cas, il s'agit de la présence de la nomenclature dans le fichier. On pourrait le dépouiller comme ça:

tail -c +4 ssl.crt > ssl2.crt

Vous ne savez pas si cela prend toujours 3 octets, alors le meilleur moyen doit être:

vi -c 'se nobomb' -c wq ssl.crt

0

J'ai eu la même erreur parce que j'ai changé .key avec les noms de fichiers .crt


0

J'ai eu un problème similaire lorsque j'ai utilisé accidentellement un cert IIS de type p7b fourni par le client dans la configuration d'Apache. La conversion du cert au format x509 a corrigé l'erreur. Les deux types se ressemblent sur la surface mais sont apparemment différents à l'intérieur.


0

J'ai eu ce problème parce qu'on m'a envoyé le contenu d'un fichier .p7b de style IIS collé dans un courrier électronique. Il a les balises "----- BEGIN CERTIFICATE -----" et "----- END CERTIFICATE -----", tout comme .pem, et le contenu utilise un codage similaire en base64. Je l'ai converti en un fichier * .pem comme ceci:

openssl pkcs7 -print_certs -in cert.p7b -out cert.cer

Après cela, Apache 2.2 était heureux.


0

J'ai récemment eu ce problème en utilisant Lets Encrypt (permetencrypt) sur Windows. Le certificat est revenu codé au format UTF-16LE. Le convertir en UTF-8 (à l’aide de dos2unix) a résolu le problème.


0

Dans mon cas, il n'y avait que les lignes vides. Quand j'ai collé le fichier crt de ntepad ou notepad ++ dans nano, j'ai toujours eu

sdgrgrgr rgregegreg rgrgreg
rgregreg rggregregr rgregrg

le fait de supprimer les espaces vides et de tout mettre en ligne a résolu le problème, par exemple:

sdgrgrgr
rgregegreg
rgrgreg
rgregreg
rggregregr
rgregrg
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.