Obtenga el certificado SSL / TLS de un servidor utilizando "openssl s_client"

Estoy tratando de obtener el certificado SSL / TLS para uno de nuestros equilibradores de carga (Netscaler) usando:

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

Pero no me mostrará el certificado:

CONNECTED(00000003)
write:errno=54

El uso -servername lb.example.comno ayuda, y nuestro administrador de sistemas me dijo que nuestros equilibradores de carga no usan SNI de todos modos.

Editar : el servidor está en nuestra intranet y no acepta conexiones de Internet público. Esta es la salida de openssl con -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

Y este es el resultado relevante de 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: */*
>

¿Alguna sugerencia sobre cómo puedo obtener el certificado usando openssl s_client?

Después de un tiempo lo descubrí: este equilibrador de carga en particular se configuró para usar solo TLSv1.2, que la versión de openssl incluida en OS X (0.9.8) no comprende. Instalé una versión más nueva de openssl (> = 1.0.1) usando homebrew para que esto funcione:

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

Estoy tratando de obtener el certificado SSL / TLS para uno de nuestros equilibradores de carga (Netscaler) usando:

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

Si es una configuración moderna (algunos renuncian a lo que eso significa), use:

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

Parece que hay algún preámbulo adicional en los bytes 0 y 1. En el byte 2, debería haber un tipo de registro. En los bytes 3 y 4 debe haber un número de versión. Los bytes 5 y 6 deben tener una longitud de 16 bits de la carga útil.

Aquí hay un ejemplo de trabajo:

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

Desde arriba, el tipo de registro está en la posición 0 y su valor es 0x16. 0x16 es el tipo de Apretón de manos. La versión de la capa de registro son los siguientes dos bytes en las posiciones 2 y 3. Sus valores son 0x03 0x01. La longitud de la carga útil es 0x007f.

Consulte también RFC 5246, Protocolo de seguridad de la capa de transporte (TLS) Versión 1.2 , página 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;

Su problema podría ser el antiguo tipo de registro compatible con SSLv2. O podría ser una versión de nivel inferior de OpenSSL de, digamos 0.9.5 o 0.9.8. Es difícil de decir, y probablemente necesitemos más información.

Más información incluiría OS; Versión OpenSSL; si intentó reemplazar la versión de OpenSSL de la plataforma con su propia versión de OpenSSL; si hay un firewall o un cuadro de "inspección web" u otra bondad de middleware ejecutándose; y lo que recibe el servidor.

El uso -servername lb.example.comno ayuda, y nuestro administrador de sistemas me dijo que nuestros equilibradores de carga no usan SNI de todos modos.

Esto suena un poco inusual. Pero es una extensión de TLS, por lo que se ignora si no se usa (y no producirá una alerta fatal).

La regla general en 2016: siempre use TLS 1.0 o superior, y siempre use SNI.