Отримайте сертифікат SSL / TLS сервера за допомогою "openssl s_client"


17

Я намагаюся отримати сертифікат SSL / TLS для одного з наших балансирів навантаження (Netscaler), використовуючи:

openssl s_client -showcerts -connect lb.example.com:443

Але він не покаже мені сертифікат:

CONNECTED(00000003)
write:errno=54

Використання -servername lb.example.comне допомагає, і наш sysadmin сказав мені, що наші балансири навантажень все одно не використовують SNI.

Редагувати : Сервер знаходиться в нашій інтрамережі і не приймає з'єднань з загальнодоступного Інтернету. Це вихід openssl з -debug:

CONNECTED(00000003)
write to 0x7fec7af0abf0 [0x7fec7b803a00] (130 bytes => 130 (0x82))
0000 - 80 80 01 03 01 00 57 00-00 00 20 00 00 39 00 00   ......W... ..9..
0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0   8..5............
0020 - 00 00 33 00 00 32 00 00-2f 00 00 9a 00 00 99 00   ..3..2../.......
0030 - 00 96 03 00 80 00 00 05-00 00 04 01 00 80 00 00   ................
0040 - 15 00 00 12 00 00 09 06-00 40 00 00 14 00 00 11   .........@......
0050 - 00 00 08 00 00 06 04 00-80 00 00 03 02 00 80 00   ................
0060 - 00 ff a6 f7 27 1a a7 18-85 cf b2 03 22 fc 48 3d   ....'.......".H=
0070 - dd a9 2c b7 76 67 62 80-df 85 ed 48 35 c7 d4 87   ..,.vgb....H5...
0080 - 8d d3                                             ..
read from 0x7fec7af0abf0 [0x7fec7b809000] (7 bytes => -1 (0xFFFFFFFFFFFFFFFF))
write:errno=54

І це відповідний вихід із curl -v https://lb.example.com/:

$ curl -vI https://lb.exmple.com/
*   Trying 1.2.3.4...
* Connected to lb.exmple.com (10.1.2.3) port 443 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate: lb.example.com
* Server certificate: RapidSSL SHA256 CA - G2
* Server certificate: GeoTrust Primary Certification Authority - G3
> HEAD / HTTP/1.1
> Host: lb.exmple.com
> User-Agent: curl/7.43.0
> Accept: */*
>

Будь-які пропозиції щодо того, як я можу отримати сертифікат за допомогою openssl s_client?


2
Ви робите це належним чином. Але, виходячи з поточної інформації, неможливо сказати, що йде не так: може бути брандмауер, що блокує рукостискання TLS, може бути проблема протоколу TLS .... Це може допомогти, якщо ви або вкажете (загальнодоступну) URL-адресу, яку ви намагаєтеся використовувати як цільову, або додасте повний вихід налагодження (варіант -debug) до свого питання.
Steffen Ullrich

Як @SteffenUllrich сказав, що це може бути TLS. Див OpenSSL ту ж помилку - можливе рішення тут .
Зіна

Відповіді:


21

Через деякий час я зрозумів: цей конкретний балансир навантаження був налаштований на використання лише TLSv1.2, який версія Opensl, включена в OS X (0.9.8), не розуміє. Я встановив нову версію openssl (> = 1.0.1) за допомогою домашньої мови, щоб це працювало:

/usr/local/opt/openssl/bin/openssl s_client -showcerts -connect lb.example.com:443

3

Я намагаюся отримати сертифікат SSL / TLS для одного з наших балансирів навантаження (Netscaler), використовуючи:

 openssl s_client -showcerts -connect lb.example.com:443

Якщо його сучасна конфігурація (деякі руки відмовляються від того, що це означає), використовуйте:

openssl s_client -connect lb.example.com:443 -tls1 -servername lb.example.com | \
openssl x509 -text -noout

CONNECTED(00000003)
write to 0x7fec7af0abf0 [0x7fec7b803a00] (130 bytes => 130 (0x82))
0000 - 80 80 01 03 01 00 57 00-00 00 20 00 00 39 00 00
...

Схоже, що в байтах 0 та 1. є додаткова преамбула. У байті 2 має бути тип запису. У байтах 3 і 4 повинен бути номер версії. Байти 5 і 6 повинні бути 16-бітовою довжиною корисного навантаження.

Ось робочий приклад:

$ openssl s_client -connect www.googl.com:443 -tls1 -servername www.googl.com -debug
CONNECTED(00000005)
write to 0x7f7fe1c1fa30 [0x7f7fe2022000] (132 bytes => 132 (0x84))
0000 - 16 03 01 00 7f 01 00 00-7b 03 01 71 c0 12 35 98
...

Зверху тип запису знаходиться в положенні 0, а його значення - 0x16. 0x16 - це рукостискання. Версія рівня запису - це наступні два байти у позиціях 2 та 3. Їх значення є 0x03 0x01. Тривалість корисного навантаження становить 0x007f.

Також див. RFC 5246, Протокол протоколу безпеки транспортного рівня (TLS), версія 1.2 , стор. 18:

6.2.1.  Fragmentation

   The record layer fragments information blocks into TLSPlaintext
   records carrying data in chunks of 2^14 bytes or less.  Client
   message boundaries are not preserved in the record layer (i.e.,
   multiple client messages of the same ContentType MAY be coalesced
   into a single TLSPlaintext record, or a single message MAY be
   fragmented across several records).

      struct {
          uint8 major;
          uint8 minor;
      } ProtocolVersion;

      enum {
          change_cipher_spec(20), alert(21), handshake(22),
          application_data(23), (255)
      } ContentType;

      struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          opaque fragment[TLSPlaintext.length];
      } TLSPlaintext;

Вашою проблемою може бути старий тип запису, сумісний з SSLv2. Або це може бути версія OpenSSL нижчого рівня, скажімо, 0,9,5 або 0,9,8. Важко сказати, і нам, мабуть, потрібна додаткова інформація.

Більше інформації міститиме ОС; Версія OpenSSL; якщо ви намагалися замінити версію OpenSSL платформи на власну версію OpenSSL; якщо є брандмауер або вікно "веб-перевірка" чи інша доброта програмного забезпечення; і що отримує сервер.


Використання -servername lb.example.comне допомагає, і наш sysadmin сказав мені, що наші балансири навантажень все одно не використовують SNI.

Це звучить якось незвично. Але його розширення на TLS, тому його ігнорують, якщо його не використовувати (і не призведе до фатального сповіщення).

Основне правило 2016 року: завжди використовуйте TLS 1.0 або вище та завжди використовуйте SNI.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.