Holen Sie sich das SSL / TLS-Zertifikat eines Servers mit "openssl s_client"

Ich versuche, das SSL / TLS-Zertifikat für einen unserer Load Balancer (Netscaler) zu erhalten, indem ich Folgendes verwende:

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

Aber das Zertifikat wird mir nicht angezeigt:

CONNECTED(00000003)
write:errno=54

Die Verwendung -servername lb.example.comhilft nicht weiter, und unser Systemadministrator hat mir mitgeteilt, dass unsere Load Balancer sowieso kein SNI verwenden.

Bearbeiten : Der Server befindet sich in unserem Intranet und akzeptiert keine Verbindungen aus dem öffentlichen Internet. Dies ist die Ausgabe von openssl mit -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

Und dies ist die relevante Ausgabe von 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: */*
>

Haben Sie Vorschläge, wie ich das Zertifikat erhalten kann openssl s_client?

Nach einer Weile habe ich es herausgefunden: Dieser spezielle Load Balancer wurde so konfiguriert, dass er nur TLSv1.2 verwendet, was die in OS X (0.9.8) enthaltene Version von openssl nicht versteht. Ich habe eine neuere Version von openssl (> = 1.0.1) mit homebrew installiert, damit dies funktioniert:

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

Ich versuche, das SSL / TLS-Zertifikat für einen unserer Load Balancer (Netscaler) zu erhalten, indem ich Folgendes verwende:

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

Wenn es sich um eine moderne Konfiguration handelt (einige verzichten darauf, was das bedeutet), verwenden Sie:

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

Es sieht so aus, als gäbe es eine zusätzliche Präambel bei Byte 0 und 1. Bei Byte 2 sollte es einen Datensatztyp geben. Bei Byte 3 und 4 sollte es eine Versionsnummer geben. Die Bytes 5 und 6 sollten eine 16-Bit-Länge der Nutzlast sein.

Hier ist ein funktionierendes Beispiel:

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

Von oben ist der Datensatztyp auf Position 0 und sein Wert ist 0x16. 0x16 ist der Handshake-Typ. Die Record-Layer-Version sind die nächsten zwei Bytes an den Positionen 2 und 3. Ihre Werte sind 0x03 0x01. Die Länge der Nutzlast beträgt 0x007f.

Siehe auch RFC 5246, TLS-Protokoll (Transport Layer Security) Version 1.2 , Seite 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;

Ihr Problem könnte der alte SSLv2-kompatible Datensatztyp sein. Oder es könnte eine Down-Level-Version von OpenSSL sein, z. B. 0.9.5 oder 0.9.8. Es ist schwer zu sagen und wir brauchen wahrscheinlich mehr Informationen.

Weitere Informationen wären OS; OpenSSL-Version; wenn Sie versucht haben, die Plattformversion von OpenSSL durch Ihre eigene Version von OpenSSL zu ersetzen; wenn eine Firewall oder eine "Web Inspect" -Box oder eine andere Middleware ausgeführt wird; und was der Server empfängt.

Die Verwendung -servername lb.example.comhilft nicht weiter, und unser Systemadministrator hat mir mitgeteilt, dass unsere Load Balancer sowieso kein SNI verwenden.

Das klingt ungewöhnlich. Aber es ist eine Erweiterung von TLS, daher wird es ignoriert, wenn es nicht verwendet wird (und es wird keine fatale Warnung erzeugt).

Die Faustregel für 2016: Verwenden Sie immer TLS 1.0 oder höher und immer SNI.