Dotaz: https - self-signed cerifikát

[pavele]

Jaký je správný postup pro vytvoření self-signed certifikátu?

1. Vytvořím klíč pro certifikační autoritu CA.key.
2. Pomocí CA.key vytvořím žádost CA.csr.
3. Pomocí CA.key a CA.csr podepíšu žádost a vytvořím certifikát CA.crt


4. Vytvořím klíč pro můj webový server MUJWEB.key.
5. Pomocí MUJWEB.key vytvořím žádost MUJWEB.csr.
6. Pomocí CA.key a CA.crt podepíšu žádost MUJWEB.csr a vytvořím certifikát MUJWEB.crt


7. Vytvořím klíč pro klienta mého webového serveru KLIENT.MUJWEB.key.
8. Pomocí KLIENT.MUJWEB.key vytvořím žádost KLIENT.MUJWEB.csr.
9. Pomocí CA.key a CA.crt podepíšu žádost KLIENT.MUJWEB.csr a vytvořím certifikát KLIENT.MUJWEB.crt
10. Převedu KLIENT.MUJWEB.crt na KLIENT.MUJWEB.pk12

Otázka: Je špatně, pokud vynechám body 4, 5 a 6 a pro webový server použiju CA.crt?

---

---

Odpovědi

[Jendа]

Self-signed znamená, že je podepsán sám sebou, žádná CA tam nefiguruje. Podle mě nemáš na mysli selfsigned, ale vlastní CA.

Je špatně, pokud vynechám body 4, 5 a 6 a pro webový server použiju CA.crt?

Přijde mi to koncepčně divné. „Správně“ bys měl mít jednu CA, která vydá certifikáty třeba pro 5 různých serverů, a privátní klíč té CA by se na těch serverech válet neměl.

[Andrej]

Podle toho, jak definuješ špatně.

Certifikát serveru by neměl mít nastavený CA bit, protože browsery a jiné klientské aplikace se na to můžou tvářit kysele. Jinak (obecně) může být samopodepsaný.

Pokud místo certifikátu od (své) autority použiješ přímo na serveru samopodepsaný certifikát, zaděláváš si tím na určitý „logistický“ problém. S autoritou stačí, aby měl každý klient u sebe certifikát autority. Pak může ověřovat identitu všech serverů, kterým autorita v budoucnu vydá certifikát. Se samopodepsanými certifikáty musíš nějak bezpečně dostat každý certifikát na každého klienta, aby zabezpečení dávalo smysl.

[pavele]

Jedná se o intranet.

Stejně budu muset nakopírovat certifikát autority a klientský certifikát na vybrané klienty, aby se browsery netvářily "kysele" a fungovalo zabezpečení "SSLVerifyClient require" - pouze klient s cerifikátem se může připojit k serveru.

[Andrej]

Když už tam autoritu tak nebo tak máš (pro vydávání těch klientských certifikátů), pak podle mě není důvod nepoužít ji taky pro podepsání certifikátu serveru. Ušetří to manuální distribucí toho serverového certifikátu na klienty, což je pořád drobné plus, i když každý klient musí dostat svůj klientský .p12 balíček.

[Filip Jirsák]

Když používáte HTTPS přihlášení klientským certifikátem, nemusí být certifikát serveru a certifikát klienta od stejné autority. Přihlášení klienta self-signed certifikátem jsem nikdy nezkoušel - server posílá klientovi seznam autorit, jejichž certifikáty akceptuje, ale je možné, že tento seznam může být prázdný a klient pak nabídne jakýkoli certifikát. Každopádně v takovém případě asi bude jednodušší pro klienty použít opravdu vlastní CA (pokud nechcete platit za komerční certifikáty), pak ale nebudete vydávat self-signed certifikáty, ale certifikáty podepsané vaší certifikační autoritou.

[Filip Jirsák]

Self-signed certifikát znamená, že certifikát je podepsán privátním klíčem příslušným k veřejnému klíči, který je v tom certifikátu - nebo-li certifikát je podepsán sám sebou, není tam žádná certifikační autorita.

Používáte názvy souborů podle OpenSSL, takže předpokládám, že chcete vytvořit self-signed certifikát právě s ním. K tomu vám stačí jeden příkaz:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 3660

Záleží na tom, kde pak certifikát chcete použít - unixové servery obvykle používají OpenSSL rozhraní, takže jim bude vyhovovat certifikát a privátní klíč ve formátu OpenSSL. Pokud byste to chtěl použít ve Windows nebo v Javě, budete spíš potřebovat formát PFX/PKCS12, což je certifikát i s privátním klíčem v jednom souboru, takže to pomocí OpenSSL musíte převést. (V tom vašem kroku 10 máte chybu, pro vytvoření .pk12 vám nestačí jen certifikát, potřebujete k tomu i privátní klíč.)

Pokud byste to chtěl na víc, než jen jednoduché testování, nebo byste těch certifikátů potřeboval víc (a uvažoval o vlastní autoritě), doporučuju raději upravit infrastrukturu tak, abyste mohl používat certifikáty Let's Encrypt. Se self-signed certifikáty a vlastními CA budete mít čím dál tím víc problémů - HTTP se dnes používá jako aplikační protokol, konečně se víc zabezpečuje, takže se přechází na HTTPS, a tak najednou problémy s nedůvěryhodnými certifikáty neřešíte jen v prohlížeči, ale s wgetem, curl, v Gitu, Dockeru, u spousty management konzolí atd.

[pavele]

Jak mám upravit infrastrukturu, abych mohl použít pro intranet Let's Encrypt? Let's Encrypt nevydává cerifikáty pro IP based adresy pro vnitřní síť.

[Filip Jirsák]

Použijte ve vnitřní síti DNS názvy z veřejného DNS prostoru. Např. pokud máte firemní doménu example.com, použijte pro intranet adresu intranet.example.com, která se může překládat na IP adresu ve vnitřní síti a klidně se může překládat jen ve vnitřní síti. Ve veřejném DNS akorát vystavíte TXT záznam _acme-challenge.intranet.example.com, pomocí kterého to doménové jméno LE ověří.

Používat přímo IP adresy ve vnitřní síti je nešťastné, je to nepohodlné pro uživatele a když potřebujete něco změnit, musíte všem uživatelům rozeslat novou IP adresu.

[pavele]

Díky za odpovědi.

[MP]

V tom navrhu je jedna tezka chyba. V pripade nasazeni do firemni produkce je nesmysl podepisovat certifikaty pro servery/klienty pres root CA, cili rozhodne pouzit intermediate certifikat.

[Filip Jirsák]

Proč?

[pavele]

Ve firemní produkci jsem já "Root CA" a intermediate certifikát nepotřebuji, protože nejsem zprostředkující certifikační autorita navázaná na "Root CA".

Navíc se nemám na koho navázat.