Apache couchDB CA podpisał certyfikaty numer

Question

Używam instancji Apache CouchDB (wersja 1.3.0) na serwerze Ubuntu 12.10 w chmurze (AWS). Próbuję uzyskać SSL pracy na mojej instancji couchDB.

Podstawowa konfiguracja protokołu SSL jest bardzo prosta. Umieściłem mój certyfikat i klucz w katalogu i Odkomentowano następujące linie w moim local.ini pliku

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 

Mam również upewnić się, że własność na tych plików jest poprawny.

Działa to dobrze, uruchamia się serwer couchDB, bez problemu można przejść do https://mycouchdbserver.com/_utils/.

Testowanie przy użyciu OpenSSL

openssl s_client -showcerts -connect mycouchdbserver.com:443 

daje poprawny wynik dla Standardowa konfiguracja SSL

Podczas testowania konfiguracji na stronie DigiCert (firmie certs SSL zostały zakupione przez - Link Test: http://www.digicert.com/help/) I Uzyskaj następujący błąd:

Serwer nie wysyła wymaganego pośredniego certyfikatu.

Przy zakupie certyfikatu SSL uzyskałem certyfikat pośredni od DigiCert i pobrałem certyfikat główny również dla DigiCert.

W local.ini plik konfiguracyjny dla couchdb można użyć tych z następujących dziedzin konfiguracja:

verify_ssl_certificates = true 
cacert_file = xxxx 

Moim problemem jest to, że nie mogę uzyskać to do pracy i próbowałem wszystkich możliwych kombinacji, aby uzyskać to praca. Oto co próbowałem:

1. próbowano ustawienie cacert_file do pośredniego cert z DigiCert
2. próbowano ustawienie cacert_file do certyfikatu głównego w/etc/ssl/CERT
3. Próbowałem dodanie cert korzeniowy ze strony DigiCert do/usr/shared/ca-certs/a następnie uruchomione dpkg-reconfigure ca-certificates, aby zainstalować nowy certyfikat główny i ustawić plik cacert_file na ten nowy certyfikowany kod pem w/etc/ssl/certs
4. Próbowano połączyć certyfikat i produkt pośredni cert w jednym pliku używanym do pliku cert_file
5. Wypróbowane łączenie certyfikatu, pośredniego certyfikatu i certyfikatu głównego w 1 pliku pem używanym dla pliku cert_file

Wszystkie powyższe błędy są zgłaszane w dzienniku couchDB. Niektóre dają kwotę masowej produkcji w dzienniku błędów, ale przy użyciu numer 3, mam

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

i testowanie z OpenSSL uzyskać

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: 

Czy ktoś ma jakiś pomysł, w jaki sposób korzystać z verify_ssl_certificates , certyfikat główny i certyfikat pośredni poprawnie z couchDB

Przeczytałem całą dokumentację online i nic nie pomogło

Dzięki z góry Andrew

Answer 1

dla każdego, kto jest zainteresowany to jak w końcu rozwiązać problem:

Wydaje się, że nie mogliśmy dostać couchdb aby prawidłowo współpracować z naszym pośredniego certyfikatu.

Ponieważ uruchamiamy nasz serwer couchDB na instancji AWS EC2, właśnie stworzyłem instancję ELB (Elastic Load Balancer) i przesłałem moje certyfikaty do ELB, a następnie dodałem instancję EC2 pod moim load balancerem i przekierowałem mój DNS do system równoważenia obciążenia (w tym przypadku także przy użyciu Route53).

Następnie całkowicie wyłączyłem SSL na couchDB i przekazałem handshake SSL do systemu równoważenia obciążenia, który obsługuje używanie pośredniego certyfikatu.

To znaczy, że komunikacje między ELB i couchDB są niepewne, ale dla nas jest to w porządku.

Oznacza to również, że teraz możemy dodać więcej serwerów couchDB w ramach ELB w celu skalowalności, aby 2 ptaki 1 kamień rozwiązanie.

Możesz zrobić to samo z Nginxem, ale dodanie i zarządzanie ELB jest łatwe i stabilne, więc poszliśmy z rozwiązaniem ELB.

Answer 2

Jest kilka rzeczy, na które CouchDB jest wrażliwy. Jednym z problemów jest formularz ponownego wystawienia namecheap. Jeśli użyjesz namecheap do przetwarzania swojego CSR, będziesz mieć problemy. Na przykład, kupiłem cert RapidSSL przez Namecheap, aw celu jej wznowienie właściwie musiałem przejść bezpośrednio do GeoTrust dostać cert robocza: https://products.geotrust.com/orders/orderinformation/authentication.do

Aby utworzyć certyfikatów SSL, zrobiłem co następuje:

$ openssl genrsa -des3 -out server.pem 2048 

Użyto frazę hasła. Musi być użyty do innych poleceń, nie zapomnij o tym.

Tworzenie żądania cert:

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

tylko odpowiedzieć na następujące:

• Kraj
• State
• Miejscowość
• Organizacja
• Nazwa zwyczajowa

Wszystkie pozostałe pytania pozostały puste.

To polecenie tworzy klucz prywatny, który będzie używać CouchDB:

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

pytany o CSR, obok zawartości pliku server.csr w polu tekstowym.

Po kilku wiadomościach e-mail otrzymasz certyfikat. Kolejną kwestią jest to, jak CouchDB obsługuje łańcuchowy certyfikat. Nie martw się o tworzenie powiązanego certyfikatu; zignoruj ​​pośrednie crt, potrzebujesz tylko specyficznego certyfikatu dla twojej domeny, aby couchdb działał poprawnie.

Zmień następujące linie w couchdb local.ini pliku:

[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 

Nie jestem pewien, czy to będzie różnica, ale upewnij się, że uprawnienia do CERT SSL są ustawione na 600. Również upewnij się chown certyfikatów przez użytkownika procesu CouchDB:

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

i uruchom ponownie serwer:

sudo /etc/init.d/couchdb restart 

Answer 3

Podsumowanie: Będziesz potrzebował CouchDB 1.6.0 lub nowszej, aby to działało (lub załataj swoją bieżącą wersję).

Miałem takie same problemy z uruchomieniem CouchDB 1.4.0 lub Raspberry Pi (raspbian jessie).

I potwierdzona z poleceniem przez serwer CouchDB został tylko wysyłając własny certyfikat, a nie całego łańcucha certyfikatów, przewidzianym spec TLS:

openssl s_client -connect myhostname:6984 -showcerts 

ta wykazała tylko jeden certyfikat. Ponadto zgłosiło błąd weryfikacji. Mój certyfikat pochodzi od Namecheap. Chociaż mam zainstalowany certyfikat główny wydawcy (COMODO RSA) na komputerze klienta, do ukończenia łańcucha wymagany jest co najmniej jeden certyfikat pośredni.

Należy pamiętać, że niektóre przeglądarki mogą automatycznie pobierać certyfikaty pośrednie, a wszystko wygląda poprawnie. Jednak większość narzędzi wiersza poleceń (curl, perl, python, openssl) nie powiodło się. Interesujące było również to, że w przeglądarce Chrome systemu Android od czasu do czasu pokazywał zieloną blokadę (wszystko dobrze), a innym razem zgłosił, że nie można zweryfikować witryny. Podejrzewam, że używa pamięci podręcznej lokalnego certyfikatu. Jeśli zdarzyło mi się przeglądać witrynę, która dostarczała te same pośrednie certyfikaty, weryfikacja byłaby następnie sukcesem dla mojego serwera CouchDB, dopóki pamięć podręczna nie zostanie wyczyszczona.

Po wykopaniu w CouchDB i źródle Erlang, znalazłem: Erlang można przekazać plik PEM jako "plik cacert". Jest to używane zarówno do sprawdzania certyfikatów klienta (jeśli jest włączony), jak i do komponowania pełnego łańcucha certyfikatów, który ma zostać wysłany do klienta w komunikacie Certyfikat TLS. Jednak moja wersja CouchDB nie mijał cacertfile argumentu, chyba jeden określony cacert_fileIverify_ssl_certificates = true. Jeśli jednak warunki te są spełnione, pomija klucz serwera i certyfikat!

Znalazłem, że został już zgłoszony jako błąd COUCHDB-2028. Zauważ, że błąd mówi, że zostało to rozwiązane w wersji 1.7.0, która moim zdaniem nie istnieje.

Znalazłem the fix was applied to the official CouchDB repository w dniu 2014-01-30.Niestety oficjalna historia zmian nie pokazuje poprawki, ale przeszukiwanie repozytorium git pokazuje, że poprawka została oficjalnie wydana w CouchDB 1.6.0.

W moim przypadku mogłem pobrać i skompilować i zainstalować CouchDB 1.6.1 ze źródła. Teraz powyższe polecenie openssl pokazuje łańcuch 4 certyfikatów wysłanych przez serwer CouchDB. Dostarczam klucz serwera i certyfikat, a także cacert_file wraz z pakietem CA pobranym z Namecheap. verify_ssl_certificates jest fałszywe. Wszystkie testowane przeze mnie przeglądarki ufają witrynie, a moje narzędzia linii poleceń działają bez hacków, aby wyłączyć weryfikację.