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
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 openssl. Vygenerová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ší.
