Подтвердить что ты не робот

Команда OpenSSL для проверки наличия сертификата сервера

Я пытаюсь запустить команду openssl, чтобы сузить то, что может быть проблемой SSL при попытке отправить исходящее сообщение из нашей системы.

Я нашел эту команду в другом разделе: Использование openssl для получения сертификата с сервера

openssl s_client -connect ip:port -prexit

Результат этого результата в

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

Означает ли это, что сервер не представляет никакого сертификата? Я пробовал другие системы на другом ip-порту и успешно выдал сертификат.

Влияет ли взаимная аутентификация на эту команду с помощью -prexit?

- Update -

Я снова запустил команду

openssl s_client -connect ip:port -prexit

И теперь я получаю этот ответ

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

Я добавил -ssl3 в команду

openssl s_client -connect ip:port -prexit -ssl3

Ответ:

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

Также пытается -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)
---
4b9b3361

ОТВЕТЫ

Ответ 1

Я отлаживал проблему с SSL сегодня, в результате чего произошла ошибка write:errno=104. В конце концов я выяснил, что причиной такого поведения было то, что сервер потребовал, чтобы SNI (servername TLS extensions) работал правильно. При поставке опции -servername в openssl он успешно подключился:

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

Надеюсь, что это поможет.

Ответ 2

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

Это ошибка рукопожатия. Другая сторона закрывает соединение, не отправляя никаких данных ( "читать 0 байтов" ). Возможно, другая сторона вообще не говорит на SSL. Но я видел аналогичные ошибки в сломанной реализации SSL, которые не понимают более новую версию SSL. Попробуйте, если вы получите SSL-соединение, добавив -ssl3 в командную строку s_client.

Ответ 3

В моем случае сертификат ssl не был настроен для всех сайтов (только для версии www, с которой перенаправлена ​​версия, отличная от www). Я использую Laravel forge и Nginx Boilerplate config

У меня была следующая конфигурация для моего сайта 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;
}

Итак, после перемещения (вырезания и вставки) следующая часть файла /etc/nginx/h 5bp/directive-only/ssl.conf работала, как ожидалось:

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

Поэтому недостаточно иметь ключи, указанные только для версии www, даже если вы вызываете только www-версию напрямую!

Ответ 4

Я также получал следующее, пытаясь выйти на github.com, поскольку наш прокси-сервер перезаписывает HTTPS-соединение с помощью своего самоподписанного сертификата:

нет сертификата однорангового узла Нет сертификата клиента Имена CA отправлены

В моем выводе также было:

Протокол: TLSv1.3

Я добавил -tls1_2 и он работал нормально, и теперь я вижу, какой CA он использует в исходящем запросе. например:
openssl s_client -connect github.com:443 -tls1_2