Skip to main content

13.7 Vlastná certifikačná autorita

Certifikát podpísaný vlastnou certifikačnou autoritou

Hoci to na prvý pohľad môže vyzerať ako nezmysel, pre vlastné VPN spojenia a tunely nie je nutné využívať verejnú certifikačnú autoritu (CA) - môžeme si vytvoriť vlastnú a jej verejný kľúč nasadiť na zariadenia pod našou správou. Je to podobná situácia ako self-signed certifikáty s tým rozdielom, že self-signed je v tomto prípade certifikačná autorita.

Vytvorenie certifikačnej autority

Vytvorenie vlastnej CA, ako aj vydávanie a podpisovanie vlastných certifikátov, umožňuje aj MikroTik RouterOS cez WinBox ponuku System → Certificates - cez záložku Certificates dáme pridať nový certifikát pre CA:

  • Name, Common Name: ľubovoľný názov našej CA;
  • Key Size: vzhľadom na dlhú dobu platnosti zvyknú mať CA dlhší kľúč (4096 bitov);
  • Days Valid: počet dní platnosti CA býva bežne niekoľko rokov;
  • Key Usage: začiarkneme „key cert. sign“;
  • potvrdíme cez Apply a následne stlačíme tlačidlo Sign;
  • po stlačení Start sa vygeneruje kľúč a CA sa stane funkčnou;
  • tlačidlom Export môžeme uložiť verejný certifikát našej CA a nahrať ho klientom.

Vytvorenie certifikátu

Následne môžeme vytvárať bežné certifikáty a podpisovať ich:

  • Name: môžeme zadať doménové meno, prípadne aj s dodatkom o našej CA;
  • Common Name: zadáme požadované doménové meno (hlavné);
  • Subject Alt. Name: zadáme požadované doménové meno (prípadne aj ďalšie alternatívy);
  • Key Size: zvolíme požadovanú dĺžku kľúča;
  • Days Valid: môžeme zadať počet dní platnosti podľa potreby;
  • Key Usage: začiarkneme „digital signature“, „key encipherment“, „tls server“;
  • potvrdíme cez Apply a následne stlačíme tlačidlo Sign;
  • zvolíme našu CA, po stlačení Start sa vygeneruje kľúč a certifikát bude aktívny;
  • tlačidlom Export môžeme uložiť verejný certifikát, po zadaní hesla (Export Passphrase) bude uložený aj súkromný kľúč.

Odvolanie certifikátu

Medzi CA a ňou podpísanými certifikátmi je väzba - certifikáty nie je možné zmazať, ale je možné ich odvolať (Revoke). Poa po zmazaní CA sa bez varovania zmažú aj všetky ňou podpísané certifikáty.

Bezpečnostné hľadisko vlastnej CA

Využitie vlastnej CA je úplne v poriadku, pokiaľ vydávame certifikáty pre účely tunelov a VPN spojení smerovačov a iných sieťových zariadení. Je však treba byť mimoriadne obozretný v prípade, že klientmi nie sú naše sieťové zariadenia, ale priamo počítače našich používateľov.

Zaradenie našej vlastnej CA medzi dôveryhodné koreňové CA do počítača kladie na nás veľmi veľkú zodpovednosť a žiadať našich klientov, aby si nainštalovali certifikát našej CA bez obmedzení do svojho vlastného počítača, je už za hranicami prijateľnosti.

Je potrebné uvedomiť si, že dôveryhodná koreňová CA bez obmedzení môže vystaviť certifikát na čokoľvek, teda i na akékoľvek cudzie doménové meno. Máme úplnú istotu, že nedôjde k úniku privátneho kľúča našej CA? Máme istotu, že k tomu nedôjde aj v budúcnosti, keď našu pozíciu prevezme niekto iný? Privátny kľúč uložený na zariadení MikroTik nemôžeme považovať za bezpečne uložený. Každý, kto má prístup k zariadeniu, má možnosť exportovať privátny kľúč. Aj miestny správca zariadenia (smerovača, servera) teda predstavuje potenciálne riziko pre všetkých klientov organizácie.

Vnútená certifikačná autorita

Zamyslime sa nad dvoma situáciami z hľadiska bezpečnosti a zneužiteľnosti:

  • Každý, kto elektronicky komunikuje so štátom a využíva elektronické podpisovanie dokumentov cez občiansky preukaz s čipom (napríklad pre účel podania daňového priznania), si musí nainštalovať potrebný softvér. Ten medzi dôveryhodné koreňové CA používateľa pridáva Ditec D.Launcher CA (vygenerovaná CA v konkrétnom zariadení, bez obmedzení).
  • Bezpečnostné balíky (antivírusy), ktoré majú kontrolovať aj HTTPS komunikáciu, pri svojej inštalácii inštalujú vlastnú koreňovú CA, napríklad ESET SSL Filter CA (vygenerovaná CA v konkrétnom zariadení, bez obmedzení).

Obmedzenie platnosti CA

Vo všeobecnosti certifikáty umožňujú definovať veľmi dôležité obmedzenia:

  • obmedziť úroveň vnorenia, teda definovať, či CA môže vytvoriť podriadenú CA, resp. do akej hĺbky (obmedzenie basicConstraints);
  • definovať obmedzenia týkajúce sa názvu domény, pre ktorú je možné vystavovať certifikáty (obmedzenie nameConstraints).

Ani jedno, ani druhé však MikroTik RouterOS neumožňuje definovať. Navyše, podľa špecifikácií nie sú obmedzenia týkajúce sa názvu subjektu určené pre koreňové CA - softvér je povinný kontrolovať toto obmedzenie len pre CA nižších úrovní (sprostredkovateľské). Niektoré aplikácie a systémy rešpektujú tieto obmedzenia aj pri ich definovaní na úrovni koreňovej CA, no niektoré nie.

Vytvorenie vlastnej CA s obmedzeniami

Pokiaľ to teda s vlastnou CA myslíme vážne, je nutné CA vytvoriť inou cestou, napríklad cez softvér OpenSSL a dodržať ďalšie pravidlá:

  • koreňovú CA s dlhou dobou platnosti prevádzkovať na offline zariadení (bez prístupu do siete) - napríklad na odloženom starom počítači, či na Raspberry Pi;
  • toto zariadenie (resp. aspoň médium, napr. pamäťovú kartu) držať bezpečne v trezore spolu s núdzovým výtlačkom privátneho kľúča (ak by došlo k poškodeniu média) - koreňovú CA bude treba zapínať len raz za niekoľko rokov pre účely vytvorenia / obnovy sprostredkovateľských CA;
  • koreňovej CA je vhodné nastaviť obmedzenie hĺbky vnorenia na hodnotu 1 a tiež obmedzenie nameConstraints (hoci ho v súčasnosti nerešpektuje každý softvér);
  • koreňovej CA je vhodné tiež nastaviť aj možnosť revokácie certifikátov (CRL);
  • pre MikroTik RouterOS si vytvoriť samostatnú sprostredkovateľskú CA s obmedzením hĺbky vnorenia na 0 a nameConstraints pre našu doménu a kratšou dobou platnosti (zopár rokov);
  • pre vydávanie certifikátov serverom si rovnako vytvoriť ďalšiu obmedzenú samostatnú sprostredkovateľskú CA, ktorá môže byť k dispozícii na online serveri;
  • všetky koncové certifikáty vydávať len sprostredkovateľskými CA.

MikroTik RouterOS sa bráni využívaniu CA, ktoré v ňom neboli vytvorené. Z praktických experimentov sa ukázalo, že pre akceptovanie CA stačí nastaviť komentár 'Generated by RouterOS' do vlastnosti nsComment. Na ukážku je v Classroom prílohe certifikát CA (aj s privátnym kľúčom) s obmedzením pre doménu „vyucba.ssnd.sk“.


Odporúčané parametre pre generovanie certifikátov v OpenSSL:

  • koreňová CA:
    • subjectKeyIdentifier=hash
    • basicConstraints=critical,CA:true,pathlen:1
    • keyUsage=critical,keyCertSign
    • nameConstraints=critical,permitted;DNS:{doména}
    • crlDistributionPoints=URI:{URL adresa CRL}
  • sprostredkovateľská CA:
    • subjectKeyIdentifier=hash
    • authorityKeyIdentifier=keyid:always,issuer
    • basicConstraints=critical,CA:true,pathlen:0
    • keyUsage=critical,digitalSignature,keyCertSign
    • nameConstraints=critical,permitted;DNS:{doména}
    • pre MikroTik RouterOS: nsComment='Generated by RouterOS'
  • certifikát servera:
    • subjectKeyIdentifier=hash
    • authorityKeyIdentifier=keyid,issuer
    • basicConstraints=CA:false
    • keyUsage=digitalSignature,keyEncipherment
    • extendedKeyUsage=serverAuth
    • subjectAltName=DNS:{doménové meno}

Centrálna správa certifikátov cez SCEP

Pokiaľ máme veľa rôznych serverov, na ktorých potrebujeme opakovane vydávať (krátkodobé) certifikáty, je vhodné využiť SCEP server. TenProtokol SCEP (Simple Certificate Enrollment Protocol) umožňuje automatickú obnovu certifikátov a je tieždostupný dostupnýaj v MikroTik RouterOS:

  • na zariadení s CA pridáme SCEP Server pre daný certifikát CA, do Path je potrebné zadať URL cestu začínajúcu „/scep/“, napríklad /scep/vyucba;
  • na zariadení, ktoré potrebuje vydať certifikát, ho vytvoríme bežným postupom, no namiesto Sign požiadame o podpísanie certifikátu tlačidlom Sign via SCEP, kde zadáme URL nášho SCEP servera (napríklad http://vyucba.ssnd.sk/scep/vyucba);
  • na SCEP serveri môžememusíme potvrdiť vystavenie certifikátu (tlačidlo Grant);
  • prípadne je možné na strane SCEP servera vopred vygenerovať jednorazové heslo (OTP) a to zadať pri žiadosti o podpísanie certifikátu.

SCEP server musí mať v nastaveniach webového servera (IP → Services, tlačidlo Web Server) povolenú službu „SCEP“ a prípadne aj „CRL“ (pre revokácie).

Takto vygenerovaný certifikát sa bude obnovovať plne automaticky vždy po uplynutí 3/4 doby platnosti.

Aký je rozdiel medzi ACME a SCEP?

SCEP je starší protokol, vyvinutý spoločnosťou Cisco, zameraný na sieťové zariadenia v internej infraštruktúre. Teda napríklad na zabezpečenie vnútropodnikových certifikátov automaticky cez vlastnú CA. Prvotné zriadenie nového certifikátu vyžaduje manuálnu autorizáciu, následná obnova je však už automatická.

ACME je novší protokol, ktorý sa zameriava na webové servery a verejné domény. Hlavným rozdielom je overovanie doménového mena cez takzvanú výzvu (challenge). Celý proces je plne automatický. Tento protokol vyvinula skupina ISRG, ktorá stojí za Let's Encrypt.

Generovanie certifikátov cez OpenSSL

1. Vytvorenie koreňovej CA

Pre koreňovú certifikačnú autoritu je vhodné nastaviť tieto OpenSSL parametre (súbor CA.ext):

subjectKeyIdentifier=hash
basicConstraints=critical,CA:true,pathlen:1
keyUsage=critical,keyCertSign
nameConstraints=critical,permitted;DNS:{doména}
crlDistributionPoints=URI:{URL adresa CRL}

V týchto parametroch sa nachádzajú vyššie spomínané obmedzenia, aj voliteľný parameter crlDistributionPoints s URL adresou zoznamu revokovaných certifikátov (napríklad v tvare http://ca.firma.sk/root.crl), ktorú bude treba prevádzkovať. Pokiaľ to nemáme v úmysle (alebo to neumožňuje náš SCEP server), tento parameter vynecháme.

Prečo je URL adresa pre CRL len cez HTTP bez zabezpečenia?

Ak by tam bola adresa s HTTPS, vznikol by problém zacyklenia, ktorý by bol podobný otázke, či bolo skôr vajce alebo sliepka. Klient by sa mal po stiahnutí certifikátu spojiť s revokačným serverom, ale ten by použil ten istý certifikát, takže by ho mal opäť najskôr overiť… Preto sa používa nezabezpečený HTTP. Bezpečnosť ohrozená nie je, pretože samotný CRL dokument má digitálny podpis.

Následne môžeme generovať certifikát:

# 1. generovanie kľúčov: vytvorí súkromný kľúč CA.key a verejný kľúč CA.csr
openssl req -newkey rsa:4096 -keyout CA.key -utf8 -subj "/C=SK/L=Názov mesta alebo obce/O=Názov organizácie/OU=Názov organizačnej jednotky/CN=Názov certifikačnej autority" -out CA.csr
# po skončení je potrebné zadať heslo na zabezpečenie súkromného kľúča

# 2. vytvorenie certifikátu CA.crt s platnosťou 16 rokov: vezme verejný kľúč a súbor s parametrami CA.ext, podpíše súkromným kľúčom
openssl x509 -req -days 5844 -in CA.csr -extfile CA.ext -signkey CA.key -out CA.crt
# pre vykonanie je potrebné zadať heslo k súkromnému kľúču 

# 3. zmazanie dočasného verejného kľúča (CSR)
rm CA.csr

Dobu platnosti je samozrejme možné zmeniť, uvedených 5844 dní je 16 rokov. Vo všetkých názvoch je možné bez problémov použiť slovenské znaky. Nie je nutné uvádzať názov organizačnej jednotky (OU). Názov certifikačnej autority (CN) môže byť napríklad „SSND.SK root CA“.

Výsledkom tohto postupu sú dva súbory:

  • verejný certifikát CA.crt - nainštalujeme ho do všetkých zariadení organizácie;
  • súkromný kľúč CA.key, zabezpečený heslom - ten nikam nenahrávame.

2. Vytvorenie sprostredkujúcej CA

Pre každú sprostredkujúcu CA je vhodné nastaviť tieto parametre (súbor CA2.ext):

subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints=critical,CA:true,pathlen:0
keyUsage=critical,digitalSignature,keyCertSign
nameConstraints=critical,permitted;DNS:{doména}

Aj v týchto parametroch sa nachádzajú vyššie spomínané obmedzenia. Certifikát vygenerujeme o čosi zložitejším postupom - je potrebné, aby boli k dispozícii súbory CA.crt a CA.key z predošlého kroku:

# 1. generovanie kľúčov: vytvorí súkromný kľúč CA2.key a verejný kľúč CA2.csr
openssl req -newkey rsa:2048 -keyout CA2.key -utf8 -subj "/C=SK/L=Názov mesta alebo obce/O=Názov organizácie/OU=Názov organizačnej jednotky/CN=Názov certifikačnej autority" -out CA2.csr
# po skončení je potrebné zadať heslo na zabezpečenie súkromného kľúča

# 2. vytvorenie certifikátu CA2.crt s platnosťou 4 roky: vezme verejný kľúč, súbor s parametrami CA2.ext, podpíše súkromným kľúčom koreňovej CA
openssl x509 -req -days 1461 -in CA2.csr -extfile CA2.ext -CA CA.crt -CAkey CA.key -CAcreateserial -out CA2.crt
# pre vykonanie je potrebné zadať heslo k súkromnému kľúču koreňovej CA

# 3. zmazanie dočasného verejného kľúča (CSR) a pomocných súborov
rm CA2.csr *.srl

Dobu platnosti je aj v tomto prípade možné zmeniť, uvedených 1461 dní predstavuje 4 roky. Názov certifikačnej autority (CN) nastavíme podľa jej nasadenia, napríklad „SSND.SK RouterOS CA“ (ak bude nasadená na MikroTik RouterOS pre vydávanie certifikátov sieťovým zariadeniam) alebo „SSND.SK server CA“ (ak ju nasadíme na server, ktorý bude vystavovať certifikáty rôznym ďalším serverom).

Výsledkom tohto postupu sú dva súbory:

  • verejný certifikát CA2.crt - nainštalujeme ho na všetky TLS servery, ktoré budú používať certifikáty od tejto CA;
  • súkromný kľúč CA2.key, zabezpečený heslom - ten nahráme len na server, ktorý bude slúžiť ako certifikačná autorita pre vystavovanie certifikátov (môže ním byť aj MikroTik smerovač).

3. Vytvorenie certifikátu servera

Certifikáty servera už nemusíme vytvárať pomocou OpenSSL, obvykle ich generujeme už automaticky (napríklad cez SCEP na zariadení MikroTik). No pokiaľ potrebujeme vytvoriť certifikát ručne, je to samozrejme možné.

Certifikáty servera by mali mať nastavené tieto parametre (súbor server.ext):

subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:false
keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectAltName=DNS:{doménové meno}

Pozor, tentokrát nezadávame doménu, ale konkrétne doménové meno servera. Postup je podobný, no je potrebné, aby boli k dispozícii súbory CA2.crt a CA2.key z predošlého kroku:

# 1. generovanie kľúčov: vytvorí súkromný kľúč server.key a verejný kľúč server.csr
openssl req -newkey rsa:2048 -nodes -keyout server.key -utf8 -subj "/C=SK/L=Názov mesta alebo obce/O=Názov organizácie/OU=Názov organizačnej jednotky/CN=doménové meno servera" -out server.csr

# 2. vytvorenie certifikátu server.crt s platnosťou 1 rok: vezme verejný kľúč, súbor s parametrami server.ext, podpíše súkromným kľúčom sprostredkujúcej CA
openssl x509 -req -days 365 -in server.csr -extfile server.ext -CA CA2.crt -CAkey CA2.key -CAcreateserial -out server.crt
# pre vykonanie je potrebné zadať heslo k súkromnému kľúču sprostredkujúcej CA

# 3. zmazanie dočasného verejného kľúča (CSR) a pomocných súborov
rm server.csr *.srl

Výsledkom tohto postupu sú dva súbory:

  • verejný certifikát server.crt - nainštalujeme ho na konkrétny TLS server;
  • súkromný kľúč server.key - ten nahráme tiež len na tento server.
Back to top