Errore SSL: impossibile leggere il certificato del server dal file

Ho configurato SSL per il mio dominio oggi e ho riscontrato un altro problema: speravo che qualcuno potesse far luce su ..

Continuo a ricevere i seguenti messaggi di errore:

[errore] Init: impossibile leggere il certificato del server dal file /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt
[errore] Errore libreria SSL: 218529960 errore: 0D0680A8: routine di codifica asn1: ASN1_CHECK_TLEN: tag errato
[errore] Errore libreria SSL: 218595386 errore: 0D07803A: routine di codifica asn1: ASN1_ITEM_EX_D2I: errore asn1 nidificato

Sto eseguendo Apache 2.2.16 e Ubuntu 10.10. Il mio file .crt ha i tag Begin and End ed è stato copiato esattamente dall'e-mail di conferma che ho ricevuto, molto frustrante!

Saluti!

Modifica >> Quando si tenta di verificare .crt Non sembra funzionare:

>> openssl x509 -noout -text -in domain.com.crt 
impossibile caricare il certificato
16851: errore: 0906D06C: routine PEM: PEM_read_bio: nessuna linea di partenza: pem_lib.c: 650: attesa: CERTIFICATO DI AFFIDABILITÀ

Anche >>

>> openssl x509 -text -inform PEM -in domain.com.crt
impossibile caricare il certificato
21321: errore: 0906D06C: routine PEM: PEM_read_bio: nessuna linea di partenza: pem_lib.c: 650: attesa: CERTIFICATO DI AFFIDABILITÀ

>> openssl x509 -text -inform DER -in domain.com.crt
impossibile caricare il certificato
21325: errore: 0D0680A8: routine di codifica asn1: ASN1_CHECK_TLEN: tag errato: tasn_dec.c: 1316:
21325: errore: 0D07803A: routine di codifica asn1: ASN1_ITEM_EX_D2I: errore asn1 nidificato: tasn_dec.c: 380: Tipo = X509

Modifica >> (Evviva l'aiuto a proposito)

>> grep '^ -----' domain.com.crt
----- INIZIA ATTESTATO -----
----- CERTIFICATO DI FINE -----

Hanno appena inviato un'e-mail alla società che fornisce il certificato, hanno risposto>

Ho controllato il file CSR che hai fornito e posso assicurarti che questo è stato generato correttamente. L'errore che stai riscontrando è causato dal fatto che stai utilizzando una riga di comando errata per l'installazione del CSR. Dovrai modificare questo domain.com.crt dalla tua riga di comando con il nome corrispondente del tuo dominio.

• attualmente crt è impostato su mysite.com.crt - ho usato domain.com.crt come esempio

È possibile che le linee siano ^ M terminate? Questo è un potenziale problema quando si spostano file da Windows a sistemi UNIX. Un modo semplice per verificare è usare viin modalità "mostrami il binario", con vi -b /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt.

Se ogni riga termina con un controllo-M, in questo modo

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

hai un file nel formato con terminazione di linea di Windows e apache non li adora.

Le opzioni includono lo spostamento del file di nuovo, prestando maggiore attenzione; o usando il dos2unixcomando per eliminare quelli; puoi anche rimuoverli all'interno di vi, se stai attento.

Modifica : grazie a @ dave_thompson_085, che sottolinea che questa risposta non si applica più nel 2019. Cioè, Apache / OpenSSL sono ora tolleranti con ^ linee terminate M, quindi non causano problemi. Detto questo, altri errori di formattazione, diversi esempi dei quali compaiono nei commenti, possono ancora causare problemi; verificare attentamente se questi sono stati spostati tra i sistemi.

Per chiunque arrivi a questa pagina con un errore simile quando prova a leggere una richiesta di firma certificato (CSR) (nota che OP sta leggendo un certificato): assicurati di usare il comando OpenSSL giusto. x509è per i certificati ed reqè per i CSR:

openssl req -in server.csr -text -noout

vs

openssl x509 -in server.crt -text -noout

Ho appena girato in tondo su questo, e si è scoperto che avevo i certificati nel modo sbagliato - ad es

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

invece di:

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

Qualcosa da verificare se stai riscontrando questo errore.

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

Sospetto che tu abbia un problema con il formato del certificato.

Esegui entrambi i seguenti due comandi e forniscici l'output:

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

Nel mio caso, ho scoperto che il mio certificato aveva caratteri "-" diversi. Deve essere stato un problema di copia / incolla da parte dell'amministratore che ha inserito il certificato sul server, sostituendo l'editor di testo - con un carattere unicode speciale lungo la strada.

Ci sono volute ore per diagnosticare, e alla fine l'ho appena indovinato, ho modificato il certificato in vi, cancellato i caratteri "-" esistenti e li ho riscritti.

Spero che questo aiuti qualcuno.

Nel mio caso, ho riscontrato gli errori dell'OP perché chiunque avesse creato il file .crt per me in primo luogo aveva davvero creato un file formattato .PEM e lo aveva chiamato .crt.

L'ho scoperto correndo nella seguente guida utile: https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how -to-convert-li

tutto quello che dovevo fare era rinominare il mio .crt in un .pem, e avevo finito! La guida ha indicato che gli errori della domanda del PO implicano che il file di input è già formattato PEM, quindi non è possibile tentare di convertirlo in .pem da un formato DER, ed è di fatto superfluo.

Assicurarsi che il file non contenga spazi finali o iniziali all'interno del file del certificato. Accertarsi attentamente che non vi siano spazi o spazi vuoti all'interno del file del certificato, selezionando l'intero testo e cercando spazi vuoti in un editor di solo testo.

Controlla anche se effettivamente tutti i file configurati esistono e sono corretti.

Ad esempio: sull'altro tuo post dici che il tuo file .key è chiamato my domain.com.crt mentre nella configurazione vhost hai 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

Controlla di nuovo che tutti i file sopra elencati esistano davvero e siano validi.

Se qualcun altro dovesse riscontrare questo problema e i log degli errori di Apache dovessero indicare qualcosa del tipo:

Init: impossibile leggere il certificato del server dal file /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt

Assicurati di non aver scambiato la tua chiave e i file dei certificati nelle dichiarazioni nella configurazione di apache. Avevo puntato la chiave sul mio file di certificato e il certificato sul mio file di chiave. Questo post mi ha aiutato a capire il problema, ma volevo segnalarlo come un altro potenziale problema / soluzione.

Il mio problema (con lo stesso errore durante l'installazione di un nuovo server con Apache 2.4) era che Apache (2.4) non riusciva a leggere il file binario .crt. L'ho importato nel mio archivio di certificati personali (con mmc) ed esportato come X.509 (.cer) codificato in base 64. Rinominato il file esportato con lo stesso nome (.crt) (usato nel mio httpd-ssl.conf) e ha funzionato di nuovo! Lo stesso certificato ha funzionato sul mio vecchio server, forse Apache 2.4 è più rigoroso di 2.2? In bocca al lupo.

Nel mio caso, ha a che fare con la BOM presente nel file. Si potrebbe spogliarlo in questo modo:

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

Non sono sicuro se ci vogliono sempre 3 byte, quindi il modo migliore deve essere:

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

Ho avuto lo stesso errore perché ho cambiato .key con i nomi di file .crt

Ho avuto un problema simile quando ho usato accidentalmente un certificato IIS di tipo p7b fornito dal cliente nella configurazione di Apache. La conversione del certificato in formato x509 ha corretto l'errore. Entrambi i tipi sembrano uguali sulla superficie ma apparentemente diversi all'interno.

Ho avuto questo problema perché mi è stato inviato il contenuto di un file .p7b in stile IIS incollato in un'e-mail. Ha i tag "----- INIZIA CERTIFICATO -----" e "----- FINE CERTIFICATO -----", proprio come .pem, e il contenuto usa una codifica base64 dall'aspetto simile. L'ho convertito in un file * .pem in questo modo:

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

Successivamente, Apache 2.2 è stato felice.

Di recente ho riscontrato questo problema utilizzando Lets Encrypt (letsencrypt) su Windows. Il certificato è tornato codificato come UTF-16LE. La conversione in UTF-8 (usando dos2unix) ha risolto il problema.

Nel mio caso c'erano solo le righe vuote. Quando ho incollato il file crt da ntepad o notepad ++ in nano, ho sempre ottenuto smth come

sdgrgrgr rgregegreg rgrgreg
rgregreg rggregregr rgregrg

rimuovere gli spazi vuoti e mettere tutto in una riga risolto il problema Ad esempio:

sdgrgrgr
rgregegreg
rgrgreg
rgregreg
rggregregr
rgregrg