J'exploite un service web nécessitant le SSL et je prévois de changer de fournisseur d'hébergement. Afin d'éviter que nos utilisateurs ne subissent des interruptions de service pendant que les caches DNS se vident, je prévois d'envoyer les requêtes de notre ancien serveur vers le nouveau pendant quelques jours. L'ancien et le nouveau site utilisent tous deux nginx et openssl.
J'ai une configuration qui semble fonctionner parfaitement dans Chrome et Firefox, mais qui échoue dans Safari et curl.
La section de configuration du proxy dans la configuration de nginx (1.6.2) de mon ancien serveur est assez simple :
upstream droplet {
server zin.droplets.gimlet.us:443;
}
server {
listen 80;
listen 443 ssl;
server_name demo.gimlet.us;
# proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# proxy_ssl_session_reuse off;
proxy_set_header Host $host;
location / {
proxy_pass https://droplet;
}
error_log /tmp/proxy_error.log;
access_log /tmp/proxy_access.log;
}
(changement proxy_ssl_protocols
y proxy_ssl_session_reuse
ne semble pas faire de différence)
Il est intéressant de noter que les requêtes de Safari et de curl ne génèrent pas d'entrées dans mes journaux /tmp. Cependant, dans le fichier error.log principal, j'obtiens une entrée du type :
2014/11/21 17:02:08 [alert] 2937#0: worker process 13634 exited on signal 11
La sortie de curl -v suggère qu'une bonne poignée de main SSL se produit, puis quelque chose se passe mal :
$ curl -v https://demo.gimlet.us/favicon.ico
* About to connect() to demo.gimlet.us port 443 (#0)
* Trying 74.50.48.201...
* connected
* Connected to demo.gimlet.us (74.50.48.201) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* subject: description=e08NImA1P8R1ukwA; C=US; ST=Wisconsin; L=Madison; O=Nathanael Vack; CN=*.gimlet.us; emailAddress=postmaster@gimlet.us
* start date: 2014-04-10 16:59:37 GMT
* expire date: 2016-04-11 09:29:37 GMT
* subjectAltName: demo.gimlet.us matched
* issuer: C=IL; O=StartCom Ltd.; OU=Secure Digital Certificate Signing; CN=StartCom Class 2 Primary Intermediate Server CA
* SSL certificate verify ok.
> GET /favicon.ico HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8z zlib/1.2.5
> Host: demo.gimlet.us
> Accept: */*
>
* Empty reply from server
* Connection #0 to host demo.gimlet.us left intact
curl: (52) Empty reply from server
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
Il convient également de noter que faire
$ curl http://demo.gimlet.us/favicon.ico
fonctionne bien.
J'ai l'impression de rater quelque chose de très basique ici. Avez-vous des suggestions quant à l'endroit où je peux trouver d'autres idées ?
0 votes
Qu'en est-il du journal d'accès ? Le signal 11 est un défaut de segmentation qui peut être très difficile à localiser. Il pourrait éventuellement avoir à faire avec la version d'OpenSSL côté client, mais je ne suis pas sûr.
0 votes
Rien dans le journal des accès (en cas d'échec). La solution (ci-dessous) a été d'ajouter plus de directives de configuration SSL.