Dotaz: TLS - bol použitý client certificate?

[Semo]

Ladíme closed-source serverovú aplikáciu, ku ktorej sa klient pripája HTTPS/TLS spojením a autentikuje klienstkým certifikátom. Keďže ide o centrálneho správcu hesiel, tak buď sa spojenie podarí alebo skončí na "HTTP/1.1 500 Internal Server Error". Z neznámeho dovodu loguje málo alebo vobec (to rieši sa s dodávateľom).

Spojenie z klienta dokážem simulovať pomocou openssl

openssl s_client -connect <SERVERFQDN>:443 -CAfile CA-certs.pem -prexit -servername <SERVERFQDN> -no_ticket -state -cert cert.pem -key key.pem

Nedokážem ale z výstupu určiť či bol vyžiadaný/poslaný klienstký certifikát alebo nie. Výstup sa líši len v nevýznamých častiach oproti volaniu bez optionov "-cert" a "-key".

Ako mám zistiť či bol poslaný klientský certifikát?

---

---

Odpovědi

[NN]

Pridal bych parametr '-state' a v krajnim pripade '-debug'. Imho pokud server vraci 500 ta aplikace/nginx whatever nebude uplne v poradku..

[Semo]

"-state" tam uz je. Debug len vypisuje dumpy posielanych dat. Mozno sa z tych dumpov da odvodit odpoved ale podla coho v tych dumpoch to mam spoznat? "500 Internal server error" je umyselne univerzalna reakcia na kazdu chybu, aby z toho neslo nic odvodit. Ide o "bezpecnostnu" aplikaciu. Proste bud je request OK a po tom odpoveda HTTP 200 a posiela XML data, alebo inak HTTP 500.

Na https://badssl.com/ su pripravene testovacie virtual hosty na vsetky mozne pokusy okolo SSL/TLS a da sa tam hrat aj s client certificates. Tam to aj vidno, ze sa komunikacia lisi ak bol predhodeny client cert alebo nie. Ale oni to maju asi vzorovo a priatelsky nakonfigurovane. Odpovedat na otazku, ci ku TLS spojeniu bol prilozeny client certificate by snad malo byt mozne aj bez spoluprace servera. Klient to predsa musi vediet, ci nejaky certifikat posielal alebo nie.

Ukazky pre badssl.com (heslo pre private key je "badssl.com"):

# s client cert
 openssl s_client -connect client.badssl.com:443 -prexit -cert badssl.com-client.pem -servername client.badssl.com -no_ticket -state

# bez client cert
openssl s_client -connect client.badssl.com:443 -prexit -servername client.badssl.com -no_ticket -state

Pri pouziti client cert vo vypise pribude riadok

SSL_connect:SSLv3/TLS write certificate verify

(Uvedene priklady by este mali mat option "-CAfile" so zoznamom CA pre overenie servera, ale na strucnu ukazku to nie je nevyhnutne)

Lenze zaroven vidno, ze server poslal "Acceptable client certificate CA names", co je zoznam CA, pomocou ktorych podpisany client cert bude akceptovat. Co sa hodi pre pripad, ze klient ma plno certifikatov a nevie, ktory ma poslat (nijak vynimocne, ak je klientom bezny www browser).

V mojom pripade ale viem, ktory client cert chcem poslat a tusim server zoznam oblubenych CA posielat nemusi. Takze v mojom prpade neviem, ci bol client cert poslany a ani ako to zistit.

[Semo]

Pokud server vyžaduje klientský certifikát, musí si o něj říct. V požadavku může poslat oblíbené CA. Každopádně -debug nebo -msg vypisují hexdump toho, co se posílá. Certifikát je dost velký, v tom hexdumpu by nemělo být tak těžké najít, jestli tam je nebo ne.

[Filip Jirsák]

Tak po zapnuti "-msg" vidno, ci sa posiela klientsky certifikat:

...

>>> ??? [length 0005]
    16 03 03 04 ab
>>> TLS 1.2Handshake [length 04ab], Certificate
    0b 00 04 a7 00 04 a4 00 04 a1 30 82 04 9d 30 82
    02 85 a0 03 02 01 02 02 09 00 f0 bb 28 c1 63 7e
...
    d2 a2 fd 76 e1 65 54 7b 45 88 f8 28 2a b1 1d 25
    a3 55 50 be cd 1b da 69 17 ca 51
SSL_connect:SSLv3/TLS write client certificate

...

Ak sa neposiela, tak to vyzera takto:

...

>>> ??? [length 0005]
    16 03 03 00 07
>>> TLS 1.2Handshake [length 0007], Certificate
    0b 00 00 03 00 00 00
SSL_connect:SSLv3/TLS write client certificate

...

Este krajsie to vidno ak sa pri kompilacii OpenSSL zapne "enable-ssl-trace" a pri pustani s_client sa prida option "-trace". Pravdepodobne to ale znamena vlastnu kompilacii OpenSSL, pretoze to tusim nie je default.

Pri "-trace" je vo vypise info o posielanom certifikate a potom aj cely certifikat jak v parsovanej forme, tak aj v BASE64

...

Sent Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 1195
    Certificate, Length=1191
      certificate_list, length=1188
        ASN.1Cert, length=1185
------details-----
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            f0:bb:28:c1:63:7e:c9:57
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = California, L = San Francisco, O = BadSSL, CN = BadSSL Client Root Certificate Authority
        Validity
            Not Before: Nov 16 05:36:33 2017 GMT
            Not After : Nov 16 05:36:33 2019 GMT
        Subject: C = US, ST = California, L = San Francisco, O = BadSSL, CN = BadSSL Client Certificate
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c7:37:5f:11:eb:1e:4e:cf:eb:ba:48:e5:cb:a3:
                    12:2c:73:3e:46:1d:1e:9c:0d:c0:8b:83:23:da:c7:
...
         be:cd:1b:da:69:17:ca:51
-----BEGIN CERTIFICATE-----
MIIEnTCCAoWgAwIBAgIJAPC7KMFjfslXMA0GCSqGSIb3DQEBCwUAMH4xCzAJBgNV
...
Ioacp9qb0qL9duFlVHtFiPgoKrEdJaNVUL7NG9ppF8pR
-----END CERTIFICATE-----
------------------

SSL_connect:SSLv3/TLS write client certificate

...

Ak client certificate posielany nebol, tak :

...

Sent Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 7
    Certificate, Length=3
      certificate_list, length=0

SSL_connect:SSLv3/TLS write client certificate

...

[MP]

Divil by ses. Napr. SOAP vraci 500 jako OK a pak to webserver jen preda.

[Semo]

Toto je SOAP API ku CyberArk-u a HTTP 500 pouziva na signalizovanie akejkolvek chyby. Ked sa clovek nedohovori s predradenym MS IIS, tak dostava obvykle HTTP 403, ak je IIS spokojny, tak to forwarduje applikacii pod nim a ta bud posle odpoved alebo HTTP 500.