Hlavní navigace

Certifikáty prakticky s utilitou OpenSSL: formáty, prohlížení, převody a testování

9. 6. 2022
Doba čtení: 16 minut

Sdílet

 Autor: Depositphotos
Tento článek má za úkol ukázat, jak provádět některé operace s certifikáty a jak je automatizovat. Nebudeme se dnes zabývat věcmi jako certifikační autorita, kotva apod. Chci raději ukázat praktickou část.

Certifikáty dnes potkáváme všude. V případě autority Let's Encrypt a utilit jako Dehydrated či ACME.sh je nasazení snadné a funguje to celé bez problémů. V jiných případech koupíte certifikát od autority, dostanete pár souborů a zase to funguje.

Výjimečně se setkáte s potřebou převést certifikát do jiného formátu. S tím často pomohou různé online služby. Při některých operacích jim ale musíte svěřit i privátní klíč, což asi nechcete. Všechny tyto operace jdou snadno provést i z řádky, stačí utilita openssl nebo i jiné.

Nejprve asi narazíte na výraz x509; ten je definován v RFC 5280, dnes se používá verze 3. RFC se netýká jen formátu, ale i CRL a dalších věcí.

Co se dozvíte v článku
  1. Formáty souborů
  2. Základní práce s certifikáty – prohlížení
  3. Převody
  4. Poznámka k manuálům
  5. Klíče, žádosti, passphrase
  6. Automatizace
  7. Testování
  8. Máme dost výkonu?

Formáty souborů

Certifikát obsahuje veřejný klíč a identitu, buď hostname nebo organizaci a podobně. Dále je podepsán certifikační autoritou nebo sám sebou. Může obsahovat i další věci a proto existuje i více formátů.

Používaných přípon ještě více: pem, crt, cer, der, p7b, pfx a další. Přípona ale neurčuje formát, takže certifikát může být uložen i s obecnou příponou  txt.

PFX/PKCS#12

Používají se i další přípony, třeba pkcs12 nebo p12. Setkáte se s ním především na Windows, byl i navržen Microsoftem. Dnes je o tom RFC 7292. Kromě certifikátů může obsahovat i privátní klíč, tedy vše je pak v jednom souboru. Je to binární soubor, moc si v něm nepočtete.

PEM

Patrně nejpoužívanější formát. Také může obsahovat jak privátní klíč, tak certifikáty. Používá přípony crt, cer a pem. Pro samostatný soubor s klíčem se většinou používá přípona  key.

Je to textový soubor kódovaný pomocí base64. Výhodou je, že jednoduché operace, jako sloučení do jednoho souboru, můžeme provést prostým spojením souborů.

Každý certifikát nebo klíč je oddělen pomocí hlavičky a patičky:

-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

Na toto pozor, hlavičky jsou důležité, neměňte je, s obsahem souboru by pak nebylo možné pracovat.

Sem spadá i PKCS 10 – certificate request (CSR, žádost o certifikát), je zde jen jiná hlavička:

-----BEGIN CERTIFICATE REQUEST----

Tento formát budete potřebovat třeba pro server Apache.

DER

Přípona der opět může obsahovat vlastní certifikát, mezilehlé certifikáty i privátní klíč. Není tak častý, ale je oblíbený v Javě.

PB7 (.pb7)

Přípona p7b nebo p7c. Neobsahuje privátní klíč, obsahuje mezilehlé certifikáty. Používá kódování base64 kódování a popisuje ho RFC 2315.

Základní práce s certifikáty – prohlížení

Začneme prostým zobrazením certifikátu, při kterém dostaneme stejné informace, jako když si zobrazíme certifikát v internetovém prohlížeči:

$ openssl x509 -text -noout -in cert.pem

Získáme spoustu informací, některé si ukážeme a okomentujeme:

Dnes se používá verze 3:
        Version: 3 (0x2)

Sériové číslo:
    Serial Number:
        03:57:52:2e:b4:13:a5:64:fe:39:94:04:dd:32:ed:e7:05:83

Jak se hashuje
        Signature Algorithm: sha256WithRSAEncryption

Vydavatel:
    Issuer: C = US, O = Let's Encrypt, CN = R3

Platnost:
        Validity
            Not Before: Apr  5 20:55:52 2022 GMT
            Not After : Jul  4 20:55:51 2022 GMT

Common Name:
        Subject: CN = domena.cz

Informace o veřejném klíči a samotný klíč:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:b9:b6:c8:e1:57:be:4d:06:4b:1c:04:7e:07:88:
                    8f:e4:ac:95:28:51:4f:34:c5:78:b5:a0:11:ee:6f:
                    83:d8:70:47:9d:0d:99:79:45:52:17:60:6a:5b:bd:
                    5a:1c:eb:42:05:93:76:3a:66:c9:12:13:37:18:bd:
                    00:7f:9e:a8:7c:78:69:7c:13:2f:53:06:01:d4:11:
                    06:9a:33:92:f0:71:1a:9a:bb:9d:c2:3a:26:f0:75:
                    89:0e:73:69:70:8f:ec


Rozšíření - zde se mohou položky více lišit, záleží o jaký certifikát se jedná
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature

K čemu je certifikát určený:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                1E:C2:17:07:03:7B:A9:FC:D1:B6:F7:62:87:EF:65:66:75:B4:28:F5
            X509v3 Authority Key Identifier:
                keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

OCSP:
            Authority Information Access:
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/

Certifikát může obsahovat i další doménová jména, to je položka Subject Alternative Name (SAN)
            X509v3 Subject Alternative Name:
                DNS:domena.cz, DNS:www.domena.cz

Výpis jiných formátů je podobný:

$ openssl pkcs7 -print_certs -in domena.cz.p7b
$ openssl pkcs12 -info -in domena.cz.pfx

Kromě certifikátu si můžeme zobrazit i informace z žádosti. Získáme podobný výpis, který ale obsahuje méně informací:

$ openssl req -noout -text -in domena.cz.csr

Jak vidíte, parametry se u formátů liší. Co vše je možné si zjistíte takto:

$ openssl x509 --help
$ openssl pkcs12 --help
$ openssl req --help

Převody

Když už víme něco o formátech, zkusíme si převod mezi nimi. Na to samozřejmě existuje spousta online nástrojů, ale v případě některých konverzí bychom se nevyhnuli posílání privátního klíče.

PEM se samostatnými soubory do jednoho souboru pkcs12:

$ openssl pkcs12 -export -in domena.cz.crt -inkey domena.cz.key -out domena.cz.pfx

Obráceně, získání certifikátu z pkcs12:

$ openssl pkcs12 -nodes -in domena.cz.pfx -out domena.cz.crt

Pokud chceme jen klíč, postupujeme takto:

$ openssl pkcs12 -in domena.cz.pfx -nodes -nocerts

PKCS7 do PEM:

$ openssl pkcs7 -print_certs -in domena.cz.p7b -out domena.cz.crt

DER do PEM:

$ openssl x509 -inform der -in domena.cz.cer -out domena.cz.pem

Obráceně:

$ openssl x509 -outform der -in domena.cz.pem -out domena.cz.cer

Možností je více, vypsal jsem jen ty, které používám nejčastěji.

Poznámka k manuálům

Možná jedna zmínka k manuálu. OpenSSL má opravdu hodně parametrů a man openssl vám jen řekne obecné věci. Když chcete parametry ke konkrétnímu příkazu, použijte openssl příkaz --help, třeba  openssl x509 --help.

Detailní informace pak naleznete v konkrétních manuálových stránkách, například man x509, man s_client nebo  man openssl-x509.

Klíče, žádosti, passphrase

Na vše nám stále stačí utilita opensslVygenerování samotného klíče:

$ openssl genrsa -out private.key 2048

Po spuštění budete vyzváni k zadání passphrase, to je ochrana před zneužitím klíče. Při dalších operacích s klíčem po vás bude vyžadována. Pokud klíč použijete třeba ve web serveru Apache, musíte web serveru tuto frázi říct nebo ji z klíče odstranit:

$ openssl rsa -in private.key -out private_without_passphrase.key

Budete opět vyzváni k zadání passphrase a pokud ji zadáte správně, vznikne nový soubor s klíčem.

Máte naopak klíč, kde jste si frázi zrušili a chcete ji zpět?

$ openssl rsa -in private_without_passphrase.key -out private.key -des3

Chcete si u certifikační autority vydat znovu certifikát, ale nemáte původní CSR? Není problém si žádost znovu vygenerovat ze stávajícího certifikátu a privátního klíče:

$ openssl x509 -x509toreq -in domena.cz.pem -out domena.cz.csr -signkey domena.cz.key

Vytvoření žádosti o certifikát můžete buď s již existujícím klíčem:

$ openssl req -new -out domena.cz.csr -key domena.cz.key

Nebo vygenerovat nový:

$ openssl req -new -out domena.cz.csr -newkey rsa:2048 -nodes -keyout domena.cz.key

Pomíchaly se vám soubory a nevíte, který klíč je ke kterému certifikátu? Zjistíme si modulus všech souborů a ten musí souhlasit.

$ openssl rsa -noout -modulus -in  host.key
Modulus=CC307E5E6390A94D85A2405E6FDAF19FEC231FEB19751550283B727AD303A7089F44D47471F8A580847E44F76781DEF463AAD61A0AA62513A276C76C82082789F6FDBCF750BE3AE29BA1D4FBDB11DAA010840B40FAB29A2A906A99A5CCF0992A98D986A058210B5411A1E2842AA3C12BB8CCC2B89A864BE60C6C083921C4FF5C238B70090AC4A7F4B47DD525CECFFE96DACFDDDD56A93649BB45897ABF7757C2AD60E09984B24F60704ABC07F15495D5E0B2E855A96651C5580794E790E4344CFF0752FB3F25C25DFC9CB0F5840117D244D3FC2AE81D3D421D601F48633945A1182141161A1FAF70014F669EACF7221E1DFF96BDE1256119FC1B98E657852357

Protože modulus je dlouhý a očima se špatně kontroluje, trošku si pomůžeme:

$ openssl rsa -noout -modulus -in domena.cz.key | openssl sha256
$ openssl x509 -noout -modulus -in domena.cz.crt | openssl sha256
$ openssl req -noout -modulus -in domena.cz.csr | openssl sha256

Automatizace

Při generování nových žádostí se vás program zeptá na několik věcí. Je možné si práci trochu usnadnit a použít konfigurační soubor. To se může hodit při automatizaci. Takto si připravíme konfiguraci pro novou žádost:

openssl_domena.cz.cnf

[req]
prompt = no
distinguished_name = dn
req_extensions = ext
input_password = PASSPHRASE

[dn]
CN = domena.cz
emailAddress = nekdo@nekde.cz
O = Nazev organizace
L = Lokalita
C = Stat

[ext]
subjectAltName = DNS:www.domena.cz

Pak už jen spustit:

$ openssl req -new -config openssl_domena.cz.cnf -key private.key -out domena.cz.csr

Ve své distribuci najdete soubor /etc/ssl/openssl.cnf, možností je mnohem více, než jsem zde ukázal.

Testování

OpenSSL umí mnohem víc, než si jen změnit formát certifikátu. Pojďme se podívat na nějaký certifikátem zabezpečený web:

$ openssl s_client -connect seznam.cz:443 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = www.seznam.cz
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Server Temp Key: X25519, 253 bits

Parametr brief opravdu zobrazí jen nejdůležitější informace. Pokud je vše v pořádku, uvidíte OK v řádku  verificaton.

Třeba self-signed certifikát už samozřejmě bude s chybami:

$ openssl s_client -connect domena.cz  -brief
depth=0 O = Fortinet Ltd., CN = FortiGate
verify error:num=18:self signed certificate
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: O = Fortinet Ltd., CN = FortiGate
Hash used: SHA256
Signature type: RSA-PSS
Verification error: self signed certificate
Server Temp Key: ECDH, P-256, 256 bits

Bez parametru brief se dozvíme mnohem více údajů, třeba verzi TLS, použité šifrování a podobně:

...
---
No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4249 bytes and written 399 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 384 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: A962D27A73755DD7F1BB83954A1D151BE66B9D937C9647B96E65D4ACD0A8015D
    Session-ID-ctx:
    Resumption PSK: 1B9F37197352F8903A55422E5DFD47327F7ECD92425C493ACB2F4CE928D21B43C7D59B99FEA91D652C1816AF819F8410
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 20 de ff 92 95 f6 28 9f-70 8f f5 fc ce 86 89 fd    .....(.p.......
    0010 - 9f 21 64 64 ec 66 a0 db-dc 7d d4 b1 90 90 57 07   .!dd.f...}....W.
    0020 - d7 2b 1d 2f 13 8a 18 4d-95 04 45 ae 0e 2c 5c 9b   .+./...M..E..,\.
    0030 - 46 23 01 21 00 a4 99 90-43 04 71 43 04 76 2f 13   F#.!....C.qC.v/.
    0040 - 73 6d d0 8c d2 21 27 ee-68 ec 44 0c ab 53 4a 6d   sm...!'.h.D..SJm
...

Zde už se třeba dozvíme platnost certifikátu. Pokud si chcete hlídat platnost, lze ve skriptu použít třeba toto:

$ openssl s_client -connect domena.cz:443 2>/dev/null | openssl x509 -noout -enddate

Výstupem bude notAfter=Sep 2 20:57:20 2022 GMT a s tím už se dá snadno pracovat dále.

Při testování se můžete setkat se self-signed certifikátem. Jak se pozná? Úplně snadno. Jeho vydavatel bude stejný jako subject name. Můžete se potkat i s chybou self signed certificate in certificate chain, to si ukážeme:

$ openssl s_client -connect root.cz:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = root.cz
verify return:1
---
Certificate chain
 0 s:CN = root.cz
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

Položka s je subject, i je vydavatel (issuer). Na výpisu Certificate chain vidíte, jak to pěkně navazuje. R3 je mezilehlý certifikát, který podepsal náš koncový certifikát, X1 je kořenový certifikát a je vydavatelem mezilehlého R3. Protože kořenový certifikát je mezi důvěryhodnými, celá cesta je důvěryhodná a výsledkem je  Verify return code: 0 (ok).

Asi vás napadne, odkud OpenSSL vezme kořenové certifikáty a proč jim věří. V systému máte pravděpodobně nainstalovaný nějaký balík důvěryhodných certifikátů, na FreeBSD je to třeba ca_root_nss. Když jej odinstalujete a zkusíte test znovu, dopadnete takto:

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = www.seznam.cz
verify return:1
...
Verify return code: 20 (unable to get local issuer certificate)

Můžeme pracovat i s vlastní autoritou, která ve výchozím seznamu důvěryhodných není. Buď ji tedy nějakým nástrojem systému přidáme nebo lze použít parametr

$ openssl s_client -connect root.cz:443  -CAfile mystore/ISRG_Root_X1.pem

Pozor na podobný parametr capath, který funguje trošku jinak. V tom případě se certifikát vyhledává podle haše, který vzniká ze Subject Name certifikátu, tedy v tomto případě z ISRG Root X1. V adresáři specifikovaném parametrem capath musí být tedy haše. Vypadá to nějak takto:

lrwxr-xr-x  1 root  wheel    58 Jan  1 18:03 e868b802.0 -> ../../../usr/share/certs/trusted/e-Szigno_Root_CA_2017.pem
lrwxr-xr-x  1 root  wheel    60 Jan  1 18:02 e8de2f56.0 -> ../../../usr/share/certs/trusted/Buypass_Class_3_Root_CA.pem
lrwxr-xr-x  1 root  wheel    61 Jan  1 18:02 ee64a828.0 -> ../../../usr/share/certs/trusted/Comodo_AAA_Services_root.pem
lrwxr-xr-x  1 root  wheel    71 Jan  1 18:02 eed8c118.0 -> ../../../usr/share/certs/trusted/COMODO_ECC_Certification_Authority.pem
lrwxr-xr-x  1 root  wheel    67 Jan  1 18:02 ef954a4e.0 -> ../../../usr/share/certs/trusted/IdenTrust_Commercial_Root_CA_1.pem
lrwxr-xr-x  1 root  wheel    56 Jan  1 18:02 f081611a.0 -> ../../../usr/share/certs/trusted/Go_Daddy_Class_2_CA.pem
lrwxr-xr-x  1 root  wheel    80 Jan  1 18:02 f0c70a8d.0 -> ../../../usr/share/certs/trusted/SSL_com_EV_Root_Certification_Authority_EC

Více najdete v dokumentaci k OpenSSL.

Chcete vidět, jaké certifikáty vám server posílá? Může posílat více certifikátů, třeba mezilehlých. Přidejte parametr -showcerts. Ve výstupu je uvidíte a díky textové podobě je snadné je vykopírovat a dále s nimi pracovat:

$ openssl s_client -showcerts -connect root.cz:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = root.cz
verify return:1
---
Certificate chain
 0 s:CN = root.cz
   i:C = US, O = Let's Encrypt, CN = R3
-----BEGIN CERTIFICATE-----
MIIHDTCCBfWgAwIBAgISBPiTol1oBGuyn3mXn6UTjimbMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
....
J14rq6uyW/ItBXfh4BoRAAP01wR2vEKkeP9pkAWlwt1PZnI8L2LDaQQeXc5HHKuE
J8NgYnJ2UNETNX5n41Eh2YFd3AgcAvLmLBqNixNiKPcT
-----END CERTIFICATE-----
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
....
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
---
Server certificate
subject=CN = root.cz

issuer=C = US, O = Let's Encrypt, CN = R3
....

Ale nemusíme testovat jen HTTPS, co třeba šifrovaný IMAP na portu 993:

$ openssl s_client -connect imap.gmail.com:993

Nebo server podporuje starttls?

$ openssl s_client -connect localhost:143 -starttls imap

Výpisy budou shodné jako u HTTPS. Podporované jsou protokoly: smtp, pop3, imap, ftp, xmpp, xmpp-server, irc, postgres, mysql, lmtp, nntp, sieve a ldap.

Možná vás napadne, že když existuje parametr s_client, jestli existuje i s_server. Ano, více v manuálu  openssl.

Zmíním příkaz verify, který se může zdát, že se chová trošku divně. Na rozdíl od běžné verifikace nekončí při první chybě, ale pokračuje dál. Je to kvůli tomu, aby vám řekl co nejvíce informací.

Jednoduchý příklad: Byl certifikát podepsán touto autoritou?

$ openssl verify -verbose -CAFile ca.crt domena.cz.crt

Když ale chcete prověřil lokálně uložený certifikát včetně mezilehlého, správný příkaz je:

$ openssl verify -CAfile root.pem -untrusted intermediate.pem cert.pem

Proč to tak je, se dočtete třeba v mailovém příspěvku Joela Sandina.

Pokud chcete rychle získat seznam serverem podporovaných šifrovacích algoritmů, můžete sáhnout po nástroji  nmap:

$ nmap --script ssl-enum-ciphers domena.cz -p 443
Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-06 11:08 CEST
Nmap scan report for domena.cz
Host is up (0.0017s latency).

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 4096) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 4096) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 4096) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 4096) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 4096) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 4096) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
|       TLS_RSA_WITH_SEED_CBC_SHA (rsa 4096) - A
|       TLS_RSA_WITH_IDEA_CBC_SHA (rsa 4096) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher IDEA vulnerable to SWEET32 attack
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 1.50 seconds

Na straně serveru se snadno zeptáme přímo OpenSSL:

$ openssl list -cipher-algorithms
$ openssl list -digest-algorithms

Chcete-li testovat konkrétní šifru, opět se vrátíme k funkci  s_client:

$ openssl s_client -connect www.domena.cz:443 -tls1_2 -cipher AES128-SHA256

Máme dost výkonu?

OpenSSL vám dokáže i změřit, kolik toho váš hardware zvládne:

$ openssl speed  -seconds 2 rsa
Doing 512 bits private rsa's for 2s: 18118 512 bits private RSA's in 2.00s
Doing 512 bits public rsa's for 2s: 262941 512 bits public RSA's in 2.00s
Doing 1024 bits private rsa's for 2s: 5899 1024 bits private RSA's in 2.00s
Doing 1024 bits public rsa's for 2s: 94475 1024 bits public RSA's in 2.00s
Doing 2048 bits private rsa's for 2s: 820 2048 bits private RSA's in 2.00s
Doing 2048 bits public rsa's for 2s: 27382 2048 bits public RSA's in 2.00s
Doing 3072 bits private rsa's for 2s: 258 3072 bits private RSA's in 2.00s
Doing 3072 bits public rsa's for 2s: 12798 3072 bits public RSA's in 2.00s
Doing 4096 bits private rsa's for 2s: 113 4096 bits private RSA's in 2.01s
Doing 4096 bits public rsa's for 2s: 7360 4096 bits public RSA's in 2.00s
Doing 7680 bits private rsa's for 2s: 15 7680 bits private RSA's in 2.13s
Doing 7680 bits public rsa's for 2s: 2169 7680 bits public RSA's in 2.00s
Doing 15360 bits private rsa's for 2s: 3 15360 bits private RSA's in 2.55s
Doing 15360 bits public rsa's for 2s: 551 15360 bits public RSA's in 2.00s
OpenSSL 1.1.1l-freebsd  24 Aug 2021
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
                  sign    verify    sign/s verify/s
rsa  512 bits 0.000110s 0.000008s   9059.0 131470.5
rsa 1024 bits 0.000339s 0.000021s   2949.5  47237.5
rsa 2048 bits 0.002439s 0.000073s    410.0  13691.0
rsa 3072 bits 0.007752s 0.000156s    129.0   6399.0
rsa 4096 bits 0.017768s 0.000272s     56.3   3680.0
rsa 7680 bits 0.142187s 0.000922s      7.0   1084.5
rsa 15360 bits 0.848958s 0.003630s      1.2    275.5

Můžete si zvolit algoritmus, dobu a počet použitých CPU.

V článku jsem rozhodně nevyčerpal všechny možnosti OpenSSL a klidně přiznávám, že je ani všechny neznám. I při psaní článku jsem narazil na webu na několik zajímavých příkazů. Ukázal jsem, co se mi hodí při běžné práci. Budu rád, když se v diskuzi podělíte o další.

Byl pro vás článek přínosný?

Autor článku

Petr Macek studoval aplikovanou informatiku na Jihočeské univerzitě, pracuje jako síťový specialista ve firmě Kostax, s. r. o. Baví ho především FreeBSD, sítě a monitoring Cacti.