"Il certificato della chiave pubblica e la chiave privata non corrispondono" quando si utilizza il certificato emesso da Godaddy [chiuso]


86

Sto cercando di installare un certificato SSL GoDaddy su un nuovo bilanciatore del carico che sto configurando su Amazon AWS. Inizialmente ho creato il certificato su Godaddy utilizzando il programma keytool per l'installazione diretta su un server Glassfish 3.1 (Amazon linux ami). Non ho avuto problemi a ottenere quella configurazione direttamente sul server. Ora devo spostare il certificato dal server web al nuovo bilanciamento del carico. Amazon richiede che la chiave privata e i certificati siano in formato PEM, quindi ho utilizzato lo strumento "rekey" su GoDaddy per creare nuovi certificati. Quando li carico nella schermata di configurazione del bilanciamento del carico sulla console AWS Mgmt, viene visualizzato il messaggio di errore: "Il certificato della chiave pubblica e la chiave privata non corrispondono".

Ecco come creo le chiavi:

$ openssl genrsa -des3 -out private.key 2048
$ openssl req -new -key private.key -out apps.mydomain.com.csr

Quindi invio il file .csr a GoDaddy durante il processo di "rekey". Una volta completata la rekey, scarico i 2 certificati appena creati (apps.mydomain.com.crt & gd_bundle.crt). Li scarico selezionando (Apache) come tipo di server (ho provato anche "altro" e "Cpanel" ma sembrano tutti uguali).

A questo punto, rimuovo la crittografia dal file private.key utilizzando il seguente comando:

$ openssl rsa -in private.key -out private.pem

A questo punto, torno nella console AWS Mgmt, creo il load balancer, aggiungo il reindirizzamento del server sicuro e metto il contenuto dei seguenti file nei rispettivi campi a schermo dove chiede di configurare il certificato ssl:

private.pem --> Private Key
apps.mydomain.com.crt --> Public Key Certificate
gd_bundle.crt --> Certificate Chain

Quando faccio clic sul pulsante "continua" ricevo l'errore "Errore: il certificato della chiave pubblica e la chiave privata non corrispondono".

-C'è un modo per verificare che ricevo un messaggio di errore valido da Amazon? Mi sembra strano che le chiavi non corrispondano quando seguo le istruzioni di GoDaddy abbastanza da vicino.

Ho provato a creare il file private.key senza crittografia RSA prima di creare .csr e questo non sembra fare alcuna differenza.

Presumo anche che i file .crt che sto scaricando da GoDaddy siano in formato .PEM, ma non sono sicuro di come verificarlo.

Qualche idea?


1
Stack Overflow è un sito per domande di programmazione e sviluppo. Questa domanda sembra essere fuori tema perché non si tratta di programmazione o sviluppo. Vedi Quali argomenti posso chiedere qui nel Centro assistenza. Forse Super User sarebbe un posto migliore per chiedere. Vedi anche Dove posso pubblicare domande su Dev Ops? .
jww

Questo post ha più di 3 anni, perché preoccuparsi di spostarlo ora?
Felby

1
Felby - la gente spesso dice: "... ma guarda questo post e quel post". Quindi non è sufficiente mantenere in ordine i nuovi post: dobbiamo almeno ricevere un messaggio anche sui vecchi post. E per quel che vale, non credo che sia una brutta domanda. È solo un po 'fuori tema per Stack Overflow.
jww

@Felby dovresti considerare questa risposta per accettazione. È quello che la maggior parte degli sviluppatori cerca quando questo problema si presenta con AWS.
Noel Baron

Risposte:


61

Per me è stato un facile due passaggi:

  1. Converti la chiave privata in PEM:

    openssl rsa -in yourdomain.key -outform PEM

  2. Converti il ​​certificato e il bundle di certificati in PEM :

    openssl x509 -inform PEM -in yourdomain.crt

    openssl x509 -inform PEM -in bundle.crt


1
Questa particolare risposta mi ha davvero aiutato. Grazie Jonathan. Per la cronaca, tuodominio.crt è la chiave pubblica, il certificato che hai ricevuto dal tuo provider, (potrebbe essere anche un .cer)
user_v

continuo a ricevere un erroreWARNING: can't open config file: /etc/pki/tls/openssl.cnf
tq

2
@tq - anche alcuni comandi OpenSSL accettano -configun'opzione. Usalo per specificare il percorso del file di configurazione che stai utilizzando.
jww

@felby Dovrebbe contrassegnare questo come risposta accettata. Questa è l'unica risposta che non crea un problema di affidabilità SSL con i dispositivi iOS.
Noel Baron

Questa risposta è davvero utile con SSL con caratteri jolly. Devi convertire entrambi i file domain.crt e gd_bundle.crt.
Ducle

40

Solo per la cronaca e per chiunque altro stia cercando di capirlo:

tuodominio.chiave -> comando da terminale: sudo openssl rsa -in yourdomain.key -outform PEM -out yourdomain.pem -> chiave privata

tuodominio.crt -> chiave pubblica

gd_bundle.crt -> catena di certificati

e sei a posto :)


2
OMG, ho perso così tante ore con un problema, mi hai appena salvato! Ho acquistato un certificato RapidSSL: il trucco era 1) convertire la chiave privata come suggerisci qui e 2) invertire l'ordine dei certificati nella catena di certificati fornita da RapidSSL. Grazie!
MiniQuark

continua a chiedermi una password ma il mio certificato rapidssl è stato creato senza uno
tq

Il comando sudo chiederà una password amministratore, a meno che il tuo account non sia impostato per non richiedere una password tramite alcuni metodi diversi. È questa la password a cui ti riferisci anche tu?
Chris J

Per aggiungere qualcosa in cui potrebbe essere trovato da qualcuno che ne ha bisogno, abbiamo ottenuto un certificato Host Gator da un client e sembrava abbastanza ben impostato: nessuna conversione pem e il bundle CA era già concatenato insieme. Tuttavia, non entrerei in Amazon. Era la stessa cosa con l'ordine dei certificati nel pacchetto. Invertendo l'ordine, è entrato e ha funzionato.
CargoMeister

23

Sembra che il problema fosse il modo in cui stavo copiando il contenuto della chiave e dei certificati nella console di gestione AWS. Stavo usando un desktop Ubuntu in esecuzione in Virtual Box su un desktop Windows 7; copia e incolla i valori da una schermata gedit nel browser in esecuzione sulla casella di Windows. Una volta aperti i file della chiave e del certificato nella stessa casella del browser web (Windows in questo caso), i certificati sono andati a buon fine. Immagino che alcune parti del file non vengano ripristinate correttamente quando si utilizza la clipboard condivisa tra il client Virtual Box e l'host. Caso chiuso.


Puoi accettare la tua risposta in modo che la gente sappia che è stato risolto?
Phil Sturgeon

2
Strano, pensavo di averlo già accettato molto tempo fa ...
Felby

7

Abbiamo trovato una soluzione alternativa a questo problema. Avevamo gli stessi sintomi con lo stesso errore.

Quindi abbiamo provato a reinserire i codici pem ancora una volta, ma questa volta ci siamo assicurati di premere Invio una volta e assicurati che il cursore fosse su una riga vuota alla fine di ogni finestra. Poi l'abbiamo salvato. HA FUNZIONATO.

Questo ha risolto il nostro problema, quindi potrebbe risolverlo per altri.


1

Un piccolo trucchetto. Sto usando una finestra di Windows (Win 7 Pro) e quando ho usato la porta Windows di OpenSSL, i file in uscita avevano caratteri di fine riga (LF) in stile Unix.

Ho dovuto convertire il file in stile Windows (CRLF) per il caricamento della chiave privata.


0

Posso suggerirvi una soluzione alternativa e un'informazione a voi ragazzi. Generalmente tutti i certificati sono in formato file PEM. Puoi semplicemente aprire un blocco note o qualsiasi editor di testo e trascinare i file che hai ricevuto in formato file .crt. Normalmente chiamato file .PEM. Se il certificato è stato caricato nel tuo keytool, puoi esportare il certificato come file pfx da keytool. Quindi puoi separare il file pfx dalla chiave privata dal file pfx. Perché il file pfx è la combinazione del tuo certificato e della chiave privata, quindi puoi ottenere separatamente il file della chiave privata e usarlo su amazon aws.

Sospetto che ci possa essere un altro modo per installare il certificato. Potrebbe essere possibile contattare l'autorità di certificazione e c'è un modo per ottenere la riemissione del certificato.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.