web-dev-qa-db-fra.com

Commande OpenSSL pour vérifier si un serveur présente un certificat

J'essaie d'exécuter une commande openssl pour préciser le problème lié à SSL lorsque vous essayez d'envoyer un message sortant depuis notre système.

J'ai trouvé cette commande dans un autre sujet: tilisation de openssl pour obtenir le certificat d'un serveur

openssl s_client -connect ip:port -prexit

La sortie de ceci se traduit par

CONNECTED(00000003)
15841:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 121 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Cela signifie-t-il que le serveur ne présente aucun certificat? J'ai essayé d'autres systèmes sur un autre ip: port et ils présentent un certificat avec succès.

L'authentification mutuelle affecte-t-elle cette commande avec -prexit?

--Mise à jour--

J'ai relancé la commande

openssl s_client -connect ip:port -prexit

Et je reçois cette réponse maintenant

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 121 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

J'ai ajouté -ssl3 à la commande

openssl s_client -connect ip:port -prexit -ssl3

Réponse:

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1403907236
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Aussi essayer -tls1

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1403907267
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
sslopenssl
49
R Zeal

Je déboguais un problème SSL aujourd'hui qui entraînait le même write:errno=104 Erreur. Finalement, j'ai découvert que ce comportement était dû au fait que le serveur SNI requis (servername extensions TLS) devait fonctionner correctement. Fournir le -servername l’option de openssl s’est connectée avec succès:

openssl s_client -connect domain.tld:443 -servername domain.tld

J'espère que cela t'aides.

71
piit79
15841:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
...
SSL handshake has read 0 bytes and written 121 bytes

C'est un échec de la poignée de main. L'autre côté ferme la connexion sans envoyer de données ("read 0 bytes"). Il se peut que l’autre côté ne parle pas du tout de SSL. Mais j'ai vu des erreurs similaires sur une implémentation SSL brisée, qui ne comprend pas la version SSL plus récente. Essayez si vous obtenez une connexion SSL en ajoutant -ssl3 sur la ligne de commande de s_client.

9
Steffen Ullrich

Dans mon cas, le certificat SSL n'a pas été configuré pour tous les sites (uniquement pour la version www vers laquelle la version non www est redirigée). J'utilise Laravel forge et le config Nginx Boilerplate

J'ai eu la config suivante pour mon site nginx:

/etc/nginx/sites-available/timtimer.at 

server {
    listen [::]:80;
    listen 80;
    server_name timtimer.at www.timtimer.at;

    include h5bp/directive-only/ssl.conf;

    # and redirect to the https Host (declared below)
    # avoiding http://www -> https://www -> https:// chain.
    return 301 https://www.timtimer.at$request_uri;
}

server {
    listen [::]:443 ssl spdy;
    listen 443 ssl spdy;

    # listen on the wrong Host
    server_name timtimer.at;

    ### ERROR IS HERE ###
    # You eighter have to include the .crt and .key here also (like below)
    # or include it in the below included ssl.conf like suggested by H5BP

    include h5bp/directive-only/ssl.conf;

    # and redirect to the www Host (declared below)
    return 301 https://www.timtimer.at$request_uri;
}

server {
    listen [::]:443 ssl spdy;
    listen 443 ssl spdy;

    server_name www.timtimer.at;

    include h5bp/directive-only/ssl.conf;

    # Path for static files
    root /home/forge/default/public;

    # FORGE SSL (DO NOT REMOVE!)
    ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
    ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;

    # ...

    # Include the basic h5bp config set
    include h5bp/basic.conf;
}

Donc, après avoir déplacé (coupé et collé) la partie suivante dans le fichier /etc/nginx/h5bp/directive-only/ssl.conf tout s'est déroulé comme prévu:

# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;

Il ne suffit donc pas de spécifier les clés uniquement pour la version www, si vous appelez uniquement la version www!

2
Alexander Taubenkorb

J'obtenais aussi le message ci-dessous en essayant de contacter github.com lorsque notre mandataire réécrit la connexion HTTPS avec son certificat auto-signé:

aucun certificat homologue disponible Aucun certificat client Noms de CA envoyés

Dans ma sortie il y avait aussi:

Protocole: TLSv1.3

J'ai ajouté -tls1_2 et cela a bien fonctionné et je peux maintenant voir quelle autorité de certification elle utilise pour la demande sortante. par exemple.:
openssl s_client -connect github.com:443 -tls1_2

0
Elijah Lynn