Commande OpenSSL pour vérifier si un serveur est la présentation d'un certificat

Je suis en train de lancer une commande openssl afin d'affiner le problème SSL peut-être lorsque vous tentez d'envoyer un message sortant de notre système.

J'ai trouvé cette commande dans un autre sujet: À l'aide d'openssl pour obtenir le certificat à partir d'un serveur

openssl s_client -connect ip:port -prexit

La sortie de cette résultats dans

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
---

Est-ce à dire que le serveur n'est pas de présenter un certificat? J'ai essayé d'autres systèmes sur une autre ip:port et qu'ils présentent un certificat avec succès.

Ne authentification mutuelle affecter cette commande avec -prexit?

--Update--

J'ai couru de nouveau 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)
---

Également 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)
---

Pouvons-nous passer de ce super-utilisateur? J'ai trouvé la question elle-même utile car il constitue déjà une solution de contournement.
Assurez-vous que vous avez utilisé apn de certificat, pas de certificat de développement ios.

InformationsquelleAutor R Zeal | 2014-06-27

openssl ssl

71

J'ai été le débogage d'un problème SSL aujourd'hui, ce qui a abouti à la même write:errno=104 erreur. Finalement, j'ai trouvé que la raison de ce comportement est que le serveur nécessaire SNI (servername extensions TLS) pour fonctionner correctement. La fourniture de la -servername option pour openssl fait se connecter avec succès:
```
openssl s_client -connect domain.tld:443 -servername domain.tld
```
Espère que cette aide.
- merci! cela a été la clé pour moi
- Merci, de votre réponse j'ai eu une astuce pour résoudre le serveur.
- Pouvez vous s'il vous plaît mettre à jour le correctif pour cela. Sera utile.
- Cela fonctionne comme un charme! Et merci beaucoup pour expliquer la SNI qui nous a aidé à la résolution d'un CDN origine problème d'accès à la! 🙂
InformationsquelleAutor piit79
9
```
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 une poignée de main à l'échec. De l'autre côté ferme la connexion sans envoyer de données ("lire 0 octets"). Il pourrait être, que l'autre côté ne parle pas de SSL à tous. Mais j'ai vu des erreurs similaires sur broken SSL mise en œuvre, qui ne comprenez pas la plus récente version de SSL. Essayez, si vous obtenez une connexion SSL en ajoutant -ssl3 à la ligne de commande de s_client.
- Dans le cas d'un ancien de la mise en œuvre, le -ssl3 option pourrait aider. A l'inverse, si son, plus récente, de la mise en œuvre, puis la tls1_2 option pourrait aider. Mais je tiens à assurer un SSL/TLS serveur à l'adresse IP/Port premier.
- si vous ne spécifiez pas, il protocole avec s_client il va essayer de faire du mieux qu'il peut, il ne devrait pas être nécessaire de le forcer à utiliser une version plus récente. Mais, j'ai vu plusieurs hôtes qui vient de fermer la connexion si le Client Bonjour demande TLS 1.1 ou même TLS 1.0, car ils ne peuvent comprendre le protocole SSL 3.0.
- Merci pour l'aide! Je vais vérifier avec le serveur (point de terminaison) si elles sont correctement l'implémentation de SSL sur le serveur
InformationsquelleAutor Steffen Ullrich

Dans mon cas, le certificat ssl n'est pas configuré pour tous les sites (uniquement pour le web version non www version redirigé vers). Je suis à l'aide de Laravel forge et de la Nginx Standard config

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

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

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 le déplacement (coupe & collage) la partie suivante de la /etc/nginx/h5bp/directive-seulement/ssl.conf fichier tout a fonctionné 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 pas d'avoir les clés spécifié uniquement pour la version www même, si vous appelez seulement la www version directement!

Que diable... cela a résolu pour moi. Pourquoi est-ce qui se passe tout à coup quand il a bien fonctionné dans le passé? Ai-je mettre à niveau des logiciels sans s'en rendre compte? Je sais que mon nginx est toujours la même version d'avant. OpenSSL peut-être?

InformationsquelleAutor Alexander Taubenkorb

0

J'ai été prise en-dessous, comme bien d'essayer d'en sortir à github.com comme notre proxy ré-écrit la connexion HTTPS avec leur auto-signé cert:

pas par les pairs certificat disponible
Aucun certificat du client noms de CA envoyé

Dans ma sortie il y a aussi:

Protocole : TLSv1.3

J'ai ajouté -tls1_2 et il a bien fonctionné et maintenant, je peux voir qui CA c'est de l'utiliser sur les sortants de la demande. par exemple:

openssl s_client -connect github.com:443 -tls1_2

InformationsquelleAutor Elijah Lynn

Vous devez vous connecter pour publier un commentaire.