Názory k článku Certifikáty prakticky s utilitou OpenSSL: formáty, prohlížení, převody a testování

Veľmi pekný článok!

Mne v ňom chýba spomenúť, že v ďalšej verzii OpenSSH dôjde k vypnutiu ssh-rsa https://www.openssh.com/txt/release-8.7#:~:text=OpenSSH%20will%20disable%20the%20ssh,less%20than%20USD%2450K.

V návode by som preto pri vytváraní spomenul radšej alternatívne algoritmy ako ECDSA a ED25519 .. https://nbeguier.medium.com/a-real-world-comparison-of-the-ssh-key-algorithms-b26b0b31bfd9

Jednak k té další verzi už dávno došlo a jednak mám pocit, že si pleteš formát klíčů (který je, bohužel, také označen ssh-rsa) a autentizace. O tom píšou ve třetím odstavci té upozorňovací kapitoly.

Ups, nerozumiem, ako som to mohol takto popliesť

Nepletiete si tak trochu secure shell a secure socket layer?

9. 6. 2022, 11:00 editováno autorem komentáře

Pravda kus som sa sekol .. ďakujem za spätnú väzbu

Kdyz uz jsme off-topic - ssh-rsa se (neprekvapive) vypina kvuli sha1... rsa-sha2-256 ci rsa-sha2-512 se to netyka.

Ten odstavec s PEM se moc nevydařil. To by chtělo opravit, začíná mluvit o souborovém kontejneru *.pem ale plynule přejde ke kontejnerům *.cer,*.crt,

Cituji "Patrně nejpoužívanější formát. Také může obsahovat jak privátní klíč, tak certifikáty. Používá přípony crt, cer a" Skutečně?

Do souborového kontejneru *.crt,*.cer uložit privátní klíč nejde. Pokud ano, prosím o postup pro ověření, protože mě se to nikdy nepodařilo. Soubory crt,cer slouží pouze pro uložení(vyexpor­tování) certifikátu neboli veřejné části klíče.

Máte pravdu, je to napsané nejednoznačně a opravdu z toho jde vyvodit, že do crt dostanete certifikát i klíč zároveň.
Článek se vydával trochu narychlo, trochu kostrbatých vět se tam najde.
Děkuji za upozornění

V příponách souborů je v PKI hrozný … nepořádek. Nejsou určené přípony souborů pro konkrétní typy souborů. .pem říká jenom to, že obsah je ve formátu PEM – ale může to být certifikát, může to být privátní klíč, může tam být několik certifikátů a k nim i šifrovaný privátní klíč… .cer nebo .crt označuje soubor s certifikátem, ale neříká, v jakém je formátu. Může to být PEM, může to být formát DER uložený binárně, může to být formát DER kódovaný v BASE64 (což už je skoro PEM). DER nebo PEM ale také může být uložený s příponou .key nebo třeba .txt.

A do toho se slovo „certifikát“ běžně používá pro „soubor s certifikátem a privátním klíčem“ (třeba PFX, ale zase to může být i PEM nebo něco jiného).

Takže uložit privátní klíč do souboru s příponou .cer je dost matoucí, ale v kontextu toho zmateného názvosloví bych se vlastně vůbec nedivil, kdyby to někdo udělal.

Zas tak strasny to neni (je to tam i s obrazkem). V definici to celkem prehledne je... chaos si do toho vnasi lidi sami :)

Takhle nakreslené to vypadá samozřejmě lépe, než jsem to popsal. Že tam je .cer dvakrát si člověk ani nemusí všimnout… A pak tam není uvedené, co je certifikát, co privátní klíč.

Ale oceňuji, jak mistrně se vyhýbají tomu, aby nikde nebylo napsáno „certificate can store the server certificate, the intermediate certificate and the private key“, i když všechny ty soubory nazývají „certificate“, jak je běžné.

Hmm, priste budu muset radsi pridat obrazek :-)
Diky

Ak by mal niekto zaujem urobit si file based CA s root a intermediate certifikatom tu su shell prikazy ktore by vam mali pomoct:
https://drive.google.com/file/d/1dRQkGi1-ACTPyMIREAZJFsuOU2PadxfW/view?usp=sharing

Strasne bych rad videl implementaci let's encrypt nekde, kde ten certifikat pro tu domenu musi byt na vice nez jednom serveru...
Jak slozity to vubec je implementovat...

Jakoze je tezky mit renewal-hook, co v danem prostredi zajisti distribuci kam je potreba..?

Já používám acme-tiny, což je skript, který zařídí certifikát, a pak si ho rozkopíruju ručně kam je potřeba… Nebo jsi to myslel tak, že každý server má i vlastní privátní klíč a tedy potřebuje vlastní certifikát?

Asi si pletete pojmy. Ke kazdemu certifikatu je potrebny i privatni klic, nebo snad dokazete provozovat https pouze s certifikatem bez klice? Tak to bych chtel videt.

11. 6. 2022, 08:09 editováno autorem komentáře

Ne, neplete si pojmy. K jednomu doménovému jménu může být vystaven libovolný počet certifikátů. Takže když potřebujete mít na více serverech pro stejné doménové jméno certifikát, můžete mít na všech serverech ten stejný certifikát (pro stejnou klíčovou dvojici), nebo na každém serveru unikátní certifikát (pro unikátní dvojici klíčů), nebo mix – jeden certifikát bude na některých serverech, na jiných serverech bude jiný certifikát.

Pokud chcete unikátní certifikát na každém serveru, v ničem se to neliší od případu, kdy by ten server byl jen jeden (pokud serverů nejsou stovky, pak byste asi narazil na limity LE).

Pokud chcete certifikát vystavit jednou a rozkopírovat na více míst, na to existují různá řešení – záleží, zda chcete jen vystavit certifikát a jeho distribuci si chcete zajistit sám, nebo zda chcete kompletní systém, který zajistí i distribuci certifikátu (případně privátního klíče, ale tomu bych se spíš vyhnul).

Ukazte mi ta reseni.

Bavim se o situaci, kdy se kazdy den musi kontrolovat platnost certifikatu (protoze plati jen 3 mesice), coz znamena, ze kazda domena se po 2 mesicich ucastni procesu vystaveni noveho certifikatu, nasledne je potreba ten konkretni certifikat rodistribuovat na X serveru v ruznych zonach, klidne i ruznych typu (napr. kombinace reverzni proxy & web server). Konfigurace takovych serveru je v nejakem konfig managementu, certifikaty jsou casto v gitu stejne jako zdrojaky.

A pokud nemate kompletni CI/CD na ten konfig management, tak chci videt, jak v takovem pripade automaticky distribuujete/gi­tujete/rekonfi­gurujete/relo­adujete ruzne sluzby na ruznych serverech.

Ja neviem, zijete v praveku? Cron, ssh, scp, wget, curl, bash, ... fakt neviete vytvorit ziadne riesenie tohto problemu?

V rozsahu stovek serveru to jiz neni trivialni reseni problemu.

Já to vaše řešení neprovozuju, takže pro něj nemám hotové řešení distribuce certifikátů. Když máte certifikáty (asi i s privátními klíči) v gitu vedle zdrojáků (což bych já nikdy neudělal), potřebujete se zaháčkovat do procesu vydání certifikátu, aby po stažení certifikátu byl provolán nějaký váš skript, který ten certifikát commitne a pushne do gitu. Na to mají různí klienti podporu. A nebo prostě můžete cronem sledovat úložiště certifikátů, a pokaždé, když se tam objeví nový certifikát, commitnout a pushnout ho.

Nebo si kupte komerční certifikát s platností jeden rok.

Jen drobná pozn. k odst. 'Automatizace':
> Ve své distribuci najdete soubor /etc/ssl/openssl ...

Může být i jinde, např. v CentOS 7:
: $ find /etc -name openssl.cnf
: /etc/pki/tls/o­penssl.cnf

Fedora to ma nalinkovane, takze je to "tam aj tam" :)
ls -la /etc/ssl/open­ssl.cnf
lrwxrwxrwx. 1 root root 24 Dec 13 18:11 /etc/ssl/open­ssl.cnf -> /etc/pki/tls/o­penssl.cnf