Varnish / Nginx cached SSL certificate tajemnica - linux, ssl, nginx, lakier

Mam trzykrotnie wyrównany ładunek VarnishSerwery Rails z Nginx działającym jako odwrotne proxy dla pracowników FastCGI. Wczoraj nasz certyfikat wygasł, a ja otrzymałem nowy certyfikat od GoDaddy i zainstalowałem go. Podczas bezpośredniego dostępu do zasobów statycznych widzę zaktualizowany certyfikat, ale podczas uzyskiwania do nich dostępu z „wirtualnej subdomeny” widzę stary certyfikat. Moja konfiguracja nginx cytuje tylko mój nowy certyfikat, więc zastanawiam się, jak stary certyfikat jest wyświetlane. Usunąłem go nawet z katalogu.

przykład: https://www212.doostang.com/javascripts/base_packaged.js?1331831461 (brak problemu z certyfikatem z SSL) https://asset5.doostang.com/javascripts/base_packaged.js?1331831461 (stary certyfikat jest używany!) (mapy na www212.doostang.com)

• Załadowałem ponownie, a nawet zatrzymałem i ponownie uruchomiłem nginx, przetestowałem nginx, aby upewnić się, że jest on odczytywany z właściwej konfiguracji, i ponownie uruchomiłem lakier z nowym plikiem pamięci podręcznej.

• Kiedy zwijam plik na asset5.doostang.com, otrzymuję błąd certyfikatu:

  curl: (60) Problem z certyfikatem SSL, sprawdź, czy certyfikat CA jest OK. Detale: błąd: 14090086: procedury SSL: SSL3_GET_SERVER_CERTIFICATE: weryfikacja certyfikatu nie powiodła się Więcej szczegółów tutaj: http://curl.haxx.se/docs/sslcerts.html

  curl wykonuje weryfikację certyfikatu SSL przezdomyślnie, używając „pakietu” kluczy publicznych urzędu certyfikacji (CA) (certyfikaty CA). Jeśli domyślnie plik pakietu nie jest odpowiedni, możesz określić alternatywny plik używając opcji --cacert. Jeśli ten serwer HTTPS używa certyfikatu podpisanego przez urząd certyfikacji reprezentowany w pakiet, weryfikacja certyfikatu prawdopodobnie nie powiodła się z powodu a problem z certyfikatem (może wygasnąć lub nazwa może nie pasuje do nazwy domeny w adresie URL). Jeśli chcesz wyłączyć weryfikację certyfikatu przez curl, użyj opcja -k (lub --insecure).

• Gdy dodaję opcję -k, otrzymuję żądany plik i widzę go w moim dzienniku dostępu nginx. Nie dostaję błędu nginx, gdy nie udostępniam -k; nginx milczy na temat błędu certyfikatu.

10.99.110.27 - - [20 / Apr / 2012: 18: 02: 52 -0700] "GET /javascripts/base_packaged.js?1331831461 HTTP / 1.0" 200 5740 "-" „curl / 7.21.3 (x86_64-pc-linux-gnu) libcurl / 7.21.3 OpenSSL / 0.9.8o zlib / 1.2.3.4 libidn / 1.18 ”

Poniżej umieściłem to, co uważam za odpowiednią część konfiguracji nginx:

server {
# port to listen on. Can also be set to an IP:PORT
listen 443;
server_name www.doostang.com, *.doostang.com;

passenger_enabled on;
rails_env production;

ssl on;
ssl_certificate /.../doostang_combined.crt;
ssl_certificate_key /.../doostang.com.key;
ssl_protocols SSLv3;

# doc root
root /.../public/files;

if ($host = "doostang.com" ) {
rewrite  ^/(.*)$  https://www.doostang.com/$1  permanent;
}
}


# Catchall redirect
server {
# port to listen on. Can also be set to an IP:PORT
listen 443;

ssl on;
ssl_certificate /.../doostang_combined.crt;
ssl_certificate_key /.../doostang.com.key;

rewrite ^(.*)$ https://www.doostang.com$1;
}

Odpowiedzi:

Ba dum ching. Mój niestandardowy system równoważenia obciążenia działał nginx w celu zakończenia SSL. Nie zauważyłem tego, ale myślę, że zrobiłem wszystko poprawnie. Chodzi o to, kiedy przejmujesz operacje po przejęciu, standaryzuj i dokumentuj! Jest tam naprawdę kilku dziwnych inżynierów :)