Erreur SSL - impossible de lire le certificat du serveur à partir du fichier
J'ai configuré SSL pour mon domaine aujourd'hui et j'ai rencontré un autre problème - j'espérais que quelqu'un pourrait faire la lumière sur ..
Je reçois toujours les messages d'erreur suivants:
. : 218529960 erreur: 0D0680A8: routines d'encodage asn1: ASN1_CHECK_TLEN: balise incorrecte [Erreur] Erreur de bibliothèque SSL: 218595386 erreur: 0D07803A: routines d'encodage 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 à partir de l'e-mail de confirmation que j'ai reçu, très frustrant!
À votre santé!
Modifier >> Lorsque vous essayez de vérifier le .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: pas de ligne de départ: pem_lib .c: 650: En attente: CERTIFICAT DE CONFIANCE
Aussi >>
>> openssl x509 -text -inform PEM -in domain.com.crt impossible de charger le certificat 21321: erreur: 0906D06C: Routines PEM: PEM_read_bio: pas de ligne de départ: pem_lib.c: 650: En attente: CERTIFICAT DE CONFIANCE
>> openssl x509 -text -inform DER -in domain.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 asn1 imbriquée: tasn_dec.c: 380: Type = X509
Modifier >> (Bravo pour l'aide d'ailleurs)
>> grep '^ -----' domain.com.crt ----- BEGIN CERTIFICATE ----- ----- END CERTIFICATE -----
Je viens d'envoyer un e-mail à la société 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é correctement généré. L'erreur que vous rencontrez actuellement est due au fait que vous utilisez une mauvaise ligne de commande pour installer le CSR. Vous devrez modifier ce domain.com.crt à partir de votre ligne de commande avec le nom correspondant de 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. Une façon simple de vérifier est d'utiliser vi en mode "Montrez-moi le binaire", avec vi -b /etc/Apache2/domain.ssl/domain.ssl.crt/domain.com.crt.
Si chaque ligne se termine par un contrôle-M, comme ceci
-----BEGIN CERTIFICATE-----^M
MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM^M
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg^M
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x^M
vous avez un fichier au format de fin de ligne Windows, et Apache n'aime pas ceux-ci.
Vos options incluent le déplacement du fichier à nouveau, en faisant plus attention; ou en utilisant le dos2unix commande pour les supprimer; vous pouvez également les supprimer à l'intérieur de vi, si vous faites attention.
Edit: merci à @ dave_thompson_085, qui souligne que cette réponse ne s'applique plus en 2019. Autrement dit, Apache/OpenSSL tolèrent désormais les lignes terminées par ^ M, donc elles ne causent pas de problèmes. Cela dit, d'autres erreurs de formatage, dont plusieurs exemples différents apparaissent dans les commentaires, peuvent toujours causer des problèmes; vérifiez-les 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): assurez-vous d'utiliser la bonne commande OpenSSL. x509 est pour les certificats et req est pour les CSR:
openssl req -in server.csr -text -noout
contre
openssl x509 -in server.crt -text -noout
Je viens de tourner en rond à ce sujet, et il s'est avéré que j'avais les certificats dans le mauvais sens - 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 pour 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 "-". Doit avoir été un problème de copier/coller de la part de l'administrateur qui a placé le certificat sur le serveur, avec l'éditeur de texte en remplacement - avec un caractère unicode spécial en cours de route.
Cela a pris des heures à diagnostiquer, et à la fin j'ai juste deviné, et édité le certificat dans vi et supprimé les caractères "-" existants, et les retapés.
J'espère que cela 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 en premier avait vraiment créé un fichier . PEM formaté, et l'a nommé .crt.
J'ai découvert cela en exécutant le guide utile suivant: https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates -et-comment-les-convertir
tout ce que j'avais à faire était de renommer mon .crt en .pem, et j'avais fini! Le guide a indiqué que les erreurs de la question de l'OP impliquent que le fichier d'entrée est déjà formaté PEM, donc essayer de le convertir en .pem à partir d'un format DER ne peut pas être fait, et est en fait inutile.
Assurez-vous que votre fichier ne comporte aucun espace de fin ou de début dans le fichier de certificat. Assurez-vous soigneusement qu'il n'y a aucun espace ou espace dans votre fichier de certificat, en sélectionnant le texte entier et en recherchant des espaces vides sur un éditeur de texte uniquement.
Vérifiez également si tous les fichiers configurés existent et sont corrects.
Par exemple: sur votre autre message, vous dites que votre fichier .key est nommé mon domaine.com.crt tandis que sur la configuration de l'hôte, vous avez domaine.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 indiquent quelque chose comme:
Init: impossible de lire le certificat du 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és et de certificats dans les déclarations de la configuration Apache. J'avais pointé la clé vers mon fichier de certificat et le certificat vers mon fichier de clé. Ce message 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 personnels (avec mmc) et je l'ai exporté en X.509 encodé en base 64 (.cer). Renommé le fichier exporté au même nom (.crt) (utilisé dans mon httpd-ssl.conf) et cela a fonctionné à nouveau! Le même certificat fonctionnait sur mon ancien serveur, peut-être qu'Apache 2.4 est plus strict que 2.2? Bonne chance.
J'ai récemment rencontré ce problème en utilisant Lets Encrypt (letsencrypt) sous Windows. Le certificat est revenu codé en UTF-16LE. Le convertir en UTF-8 (en utilisant dos2unix) a résolu le problème.
J'ai eu la même erreur parce que j'ai changé de .key avec .crt noms de fichiers
J'ai rencontré un problème similaire lorsque j'ai accidentellement utilisé un type de p7b fourni par le client IIS cert dans la configuration Apache. La conversion du cert au format x509 a corrigé l'erreur. Les deux types ont le même aspect en surface mais sont apparemment différents à l'intérieur.
Dans mon cas, c'était juste les lignes vides. Quand j'ai collé le fichier crt de ntepad ou notepad ++ dans nano, j'ai toujours eu smth comme
sdgrgrgr rgregegreg rgrgreg
rgregreg rggregregr rgregrg
supprimer les espaces vides et mettre tout en ligne a résolu le problème Par exemple:
sdgrgrgr
rgregegreg
rgrgreg
rgregreg
rggregregr
rgregrg
Dans mon cas, cela a à voir avec la nomenclature présente dans le fichier. On pourrait le dépouiller ainsi:
tail -c +4 ssl.crt > ssl2.crt
Je ne sais pas si cela prend toujours 3 octets, donc la meilleure façon doit être:
vi -c 'se nobomb' -c wq ssl.crt
J'ai eu ce problème parce que j'ai reçu le contenu d'un fichier .p7b de style IIS collé dans un e-mail. Il a les balises "----- BEGIN CERTIFICATE -----" et "----- END CERTIFICATE -----", tout comme .pem, et le contenu utilise un encodage base64 similaire. 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 content.