Apache couchDB CA ha firmato problemi con il certificato

Question

Sto eseguendo un'istanza Apache CouchDB (versione 1.3.0) su un server Ubuntu 12.10 nel cloud (AWS). Sto cercando di far funzionare SSL sulla mia istanza di couchDB.

L'impostazione di base SSL è molto semplice. Ho messo il mio certificato e la chiave in una directory e non è commentato le seguenti righe nel mio file local.ini

httpsd = {couch_httpd, start_link, [https]} 
cert_file = /usr/local/etc/couchdb/certs/mycouchdbserver_cert.pem 
key_file = /usr/local/etc/couchdb/certs/mycouchdbserver_key.pem 

Ho anche fatto in modo che la proprietà su questi file è corretto.

Questo funziona correttamente, il server couchDB si avvia, è possibile navigare a https://mycouchdbserver.com/_utils/ senza problemi.

Test con OpenSSL

openssl s_client -showcerts -connect mycouchdbserver.com:443 

dà il risultato corretto per la configurazione standard SSL

Durante il test di messa a punto sul sito DigiCert (l'azienda i certificati SSL sono stati acquistati attraverso - link di prova: http://www.digicert.com/help/) I ottenere il seguente errore:

Il server non sta inviando il certificato intermedio richiesto.

Al momento dell'acquisto del certificato SSL ho ottenuto un certificato intermedio da DigiCert e ho scaricato anche il certificato radice per DigiCert.

nel file di configurazione local.ini per CouchDB è possibile utilizzare questi con i seguenti campi di configurazione:

verify_ssl_certificates = true 
cacert_file = xxxx 

Il mio problema è che non posso arrivare a questo lavoro e ho provato tutte le combinazioni possibili per arrivare a questo lavoro. Ecco quello che ho provato:

1. provato a fissare cacert_file per il CERT intermedio da DigiCert
2. provato a fissare cacert_file al certificato radice in/etc/ssl/certs
3. provato ad aggiungere il CERT della radice dal sito DigiCert to/usr/shared/ca-certs/e quindi eseguire dpkg-reconfigure ca-certificates per installare un nuovo certificato root e impostare cacert_file su quel nuovo certificato codificato in pem in/etc/ssl/certs
4. Provato combinando il cert e il intermedio cert in un file usato per cert_file
5. Provato combinando il cert, il cert intermedio e il cert root in 1 file pem utilizzato per cert_file

Tutti gli errori di cui sopra nel registro couchDB. Alcuni danno una quantità di massa di uscita nei registri errori, ma utilizzando il numero 3, ottengo

=ERROR REPORT==== 11-Jun-2013::11:35:30 === 
SSL: hello: ssl_handshake.erl:252:Fatal error: internal error 

e test con OpenSSL ottengo

CONNECTED(00000003) 
16871:error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error:s3_pkt.c:1099:SSL alert number 80 
16871:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: 

Qualcuno ha qualche idea su come utilizzare i verify_ssl_certificates , il certificato radice ed il certificato intermedio correttamente con CouchDB

ho letto tutta la documentazione in linea e niente ha aiutato

Grazie in anticipo Andrew

Answer 1

Per chi è interessato questo è il modo in cui finalmente risolto il problema:

sembra che non siamo riusciti a ottenere CouchDB per funzionare correttamente con il nostro certificato intermedio.

Poiché stiamo eseguendo il nostro server couchDB su un'istanza AWS EC2, ho appena creato un'istanza ELB (Elastic Load Balancer) e caricato i miei certificati sull'ELB, quindi ho aggiunto l'istanza EC2 sotto il mio load balancer e reindirizzato il mio DNS a il bilanciamento del carico (usando anche Route53 qui).

Ho quindi disattivato SSL completamente su couchDB e ho passato l'handshake SSL al bilanciamento del carico che supporta l'uso di un certificato intermedio.

Ciò significa che le comunicazioni tra ELB e couchDB non sono sicure, ma per noi va bene.

Ciò significa anche che ora è possibile aggiungere più server couchDB sotto l'ELB per la scalabilità, quindi 2 soluzioni 1 pietra.

È possibile eseguire la stessa soluzione anche con Nginx ma aggiungere e gestire un ELB è semplice e stabile, quindi abbiamo optato per la soluzione ELB.

Answer 2

Ci sono alcune cose a cui CouchDB è sensibile. Un problema è la forma di riemissione di namecheap. Se usi namecheap per elaborare il tuo CSR, avrai dei problemi. Per esempio, ho comprato un CERT RapidSSL attraverso Namecheap, e al fine di riemettere correttamente ho dovuto andare direttamente al GeoTrust per ottenere un CERT di lavoro: https://products.geotrust.com/orders/orderinformation/authentication.do

per creare il certificati SSL, ho fatto la seguente:

$ openssl genrsa -des3 -out server.pem 2048 

È stata utilizzata una passphrase. Deve essere usato per gli altri comandi, non dimenticarlo.

creare la richiesta di cert:

$ openssl req -new -key server.pem -out server.csr 

solo rispondere quanto segue:

• Paese
• Stato
• Località
• Organizzazione
• Nome comune

Tutte le altre domande sono state lasciate vuote.

Questo comando crea la chiave privata in chiaro che CouchDB utilizzerà:

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

Quando è stato chiesto per la csr, oltre i contenuti del file server.csr nella casella di testo.

Dopo un gruppo di e-mail, si otterrà il certificato. Un altro problema è come CouchDB gestisce il certificato incatenato. Non preoccuparti di creare un certificato incatenato; ignora il crt intermedio, hai solo bisogno del cert specifico per il tuo dominio affinché couchdb funzioni correttamente.

Modificare le seguenti righe nel file local.ini CouchDB:

[daemons] 
; enable SSL support by uncommenting the following line and supply the PEM's below. 
; the default ssl port CouchDB listens on is 6984 
httpsd = {couch_httpd, start_link, [https]} 

[ssl] 
cert_file = /path/to/ssl/cert/server.crt 
key_file = /path/to/ssl/cert/server.key 

io non sono sicuro se questo farà la differenza, ma assicurarsi che le autorizzazioni per le certificati SSL sono impostati su 600. Inoltre assicurarsi di chown i CERT dall'utente processo CouchDB:

# in the ssl cert directory 
sudo chmod 600 ./* 
sudo chown couchdb:couchdb ./* 

e riavviare il server:

sudo /etc/init.d/couchdb restart 

Answer 3

Riepilogo: Avrai bisogno di CouchDB 1.6.0 o versioni successive affinché questo funzioni (o patch la versione corrente).

Ho avuto gli stessi problemi con CouchDB 1.4.0 o un Raspberry Pi (jaspie raspbian).

ho confermato con il seguente comando che il server CouchDB è stato solo inviando il proprio certificato, invece di tutta la catena del certificato, come richiesto dalle specifiche TLS:

openssl s_client -connect myhostname:6984 -showcerts 

Questo ha mostrato un solo certificato. Inoltre, ha segnalato un errore di verifica. Il mio certificato proviene da Namecheap. Mentre ho il certificato radice dell'emittente (COMODO RSA) installato sul computer client, per completare la catena è richiesto almeno un certificato intermedio.

Si noti che alcuni browser sono in grado di recuperare automaticamente certificati intermedi e tutto sembra in ordine. La maggior parte degli strumenti da riga di comando (curl, perl, python, openssl) non è riuscita, però. Inoltre, è interessante notare che sul browser Chrome di Android ha mostrato occasionalmente un lucchetto verde (tutto in ordine) e altre volte ha segnalato che il sito non può essere verificato. Sospetto che stia usando una cache di certificati locali. Se mi è capitato di sfogliare un sito che forniva gli stessi certificati intermedi, la verifica sarebbe successivamente riuscita per il mio server CouchDB, fino a quando la cache non è stata eliminata.

Dopo aver scavato nella sorgente CouchDB e Erlang, ho trovato il seguente: Erlang può essere passato un file PEM come 'cacertfile'. Viene utilizzato sia per verificare i certificati client (se abilitati) sia per comporre l'intera catena di certificati da inviare al client nel messaggio Certificato TLS. Tuttavia, la mia versione di CouchDB non passava l'argomento cacertfile, a meno che uno specificasse cacert_fileEverify_ssl_certificates = true. Tuttavia, se tali condizioni sono soddisfatte, omette la chiave e il certificato del server!

Ho trovato che questo era già archiviato come bug COUCHDB-2028. Si noti che il bug dice che questo è stato risolto nella versione 1.7.0, che a mio avviso non esiste.

Ho trovato che the fix was applied to the official CouchDB repository in data 2014-01-30.Sfortunatamente la cronologia delle revisioni ufficiali non mostra la correzione, ma scavare attraverso il repository git mostra che la correzione è stata inizialmente rilasciata ufficialmente in CouchDB 1.6.0.

Nel mio caso, sono riuscito a scaricare, compilare e installare CouchDB 1.6.1 dal sorgente. Ora, il precedente comando openssl mostra una catena di 4 certificati inviati dal server CouchDB. Fornisco la chiave e il certificato del server, oltre allo cacert_file con il pacchetto CA scaricato da Namecheap. verify_ssl_certificates è falso. Tutti i browser che ho testato si fidano del sito, inoltre i miei strumenti della linea di comando funzionano senza hack per disabilitare la verifica.