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

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

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 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

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.

>> 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 

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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