38
szerkesztés
Módosítások
TCS
,nincs szerkesztési összefoglaló
== A KIFÜ tanúsítványszolgáltatás ==
<span style="color: red;">''2020.08.19-től nem lehet 2 éves TLS tanúsítványokat igényelni a Sectigo rendszerében!''</span>
<span style="color: red;">[https://sectigo.status.io/pages/maintenance/5938a0dbef3e6af26b001921/5f0e30f3aab0e604b91214a0 --->LINK]</span>
A ''Megbízható Tanúsítványszolgáltatás'' (Trusted Certificate Service, '''TCS''') olyan tanúsítványok kiállítását biztosítja, amelyet az elterjedt böngészők és kliensprogramok megbízhatónak tartanak, valamint bizonyos típusaik Grid hálózatokban is elfogadhatóak.
Az eléréséhez szükséges, hogy az intézmény létre legyen már hozva a felületen, és legalább egy adminisztrátor be legyen állítva. Lásd a “Belépés” részt.
A TCS rendszerben a tanúsítványokat kiállító CA (a '''[https://sectigo.com/ Sectigo]''') az igénylők azonosításának és a tanúsítványigénylések elbírálásának jogát és felelősségét átruházza a TCS rendszert használó intézmények erre felhatalmazott adminisztrátorai számára. Az igényléseket a Sectigo [[TCSValidation :TCS#Valid.C3.A1ci.C3.B3s_folyamatok| validálja]].
== Igényelhető tanúsítványok ==
== Szolgáltatás feltételei ==
A szolgáltatás kizárólag a [https://kifu.gov.hu/ Kormányzati Informatikai Fejlesztési Ügynökség] azon intézményei számára vehető igénybe, amelyek erre szerződést kötöttek a KIFÜ-vel. Amennyiben szeretné igénybevenni a KIFÜ tanúsítványszolgáltatását, kérjük írjon az [mailto:ugyfelszolgalat@kifu.hu emailcímre Ügyfélszolgálat emailcímére] vagy hívja a +3614503070 telefonszámot.
== Különbségek az előző (DigiCertes) szolgáltatóhoz képest ==
A Sectigo a GÉANT Trusted Certificate Service (TCS) szolgáltatás új szállítója a DigiCert helyett. A Sectigo Certificate Manager-t (SCM) használjuk a DigiCert CertCentral helyett. A további részben bemutatjuk a legfontosabb változásokat.
<syntaxhighlight line>
Figyelem! A Sectigo SCM platformről törölni nem lehet. Ezt azt jelenti, hogy ha tévedésből igényelt egy tanúsítványt vagy rossz DNS TLD-t küldött be DCV-re vagy elírta a ACME account nevet, akkor ezeket csak a Sectigo Support tudja törölni az SCM platformról.
</syntaxhighlight>
=== Nincs "Divízió" objektum az új rendszerben ===
Az SCM-ben nem működik a divízió koncepciója, úgy ahogyan az a DigiCert CertCentralban volt.
* A KIFÜ-nek van egy [https://cert-manager.com/customer/KIFU SCM felülete], amelyet az összes KIFÜ adminisztrátor használ (az intézmények szintjén és a KIFÜ „superuser” szintjén), de a többi GEANT TCS tagország nem fér hozzá.
* Mivel nincs az a Divizió-rendszer, mint ami a Digicertnél volt, így arra sincs lehetőség, hogy a velünk szerződött intézmények szabadon alkossanak OrganizationSzervezet-objektumokat, amiket a Divizió fog össze. Ehelyett a KIFÜ intézményi szintjén hozunk létre egy szervezet objektumot a KIFÜ intézményei számára, és ehhez adunk meg egy intézményi adminisztrátort.
* Az Organization alatt lehetőség van kisebb szervezeti egységeket, Departmenteket létrehozni, és akár saját adminisztrátorokat rendelni hozzá.
== Validációs folyamatok ==
=== Szervezet validációja ===
Az ''Organization'' létrehozásakor annak validációját a KIFÜ MRAO jogosultságú adminisztrátorai indítják el. Csak ha a validáció sikeresen lezárult, akkor tudják az intézmény adminisztrátorai érdemben használni a felületet. Az ''Organization'' adatait a RAO jogosultságú adminisztrátorok tudják szerkeszteni, viszont bizonyos mezők átírása a szervezet újbóli validációját teszi szükségessé. Ebben az esetben értesíteni kell az MRAO adminisztrátorokat, hogy indítsák el a folyamatot.
=== Domain validáció ===
A tanúsítványok kiállítása előtt érvényesítenie kell egy vagy több domaint. Ennek a folyamatnak több lépése van:
# Győződjön meg arról, hogy a DNS-zónájában nincs CAA-rekord, amely megtiltja a Sectigo számára, hogy tanúsítványokat állítson ki az adott domainra. Ebben az esetben a domain validálása kudarcot vallana. Ha hiányzik a CAA-rekord vagy ott van de tartalmazza a „sectigo.com”bejegyzést, akkor menni fog a validáció.
# Válassza a '''''Settings → Domains → Delegations''''' menüpontot, és nyomja meg az Add gombot. Töltse ki a domain nevet (example.org) és az opcionális leírást. Válassza ki a domainhez engedélyezni kívánt tanúsítványok típusát (SSL, kliens, CS). A fő domainhez általában érdemes mindet engedélyezni, de a többi kiegészítő domainhez elegendő csak az SSL tanúsítványokat. A Client Certificate és a Code Signing-ot csak akkor szabad kijelölni, ha valóban használni szeretné azokat. Ha Departmenteket hozott létre, és ezt a tartományt az adott egység DRAO-jainak kell átruházni, nyissa le a választási sort, és engedélyezze a domaint a megfelelő egységnél és állítsa be a megfelelő típusokat is.# Nyomja meg újra az Add gombot, és pontosan ugyanezeket a lépéseket kell megtenni a "*"-al kiegészített domainnév esetében is (a példánkban *.example.org). '''''Ezt mindenképpen tegye meg, hogy ne okozzon gondot az aldomainekre is igényelni tanúsítványt!'''''# Amennyiben egy DRAO jogosultságú személy vagy egy szűkített jogosultsággal bíró RAO személy indította a domain validációt, szükség van egy megfelelő jogosultságokkal rendelkező RAO vagy egy MRAO engedélyezésére is a delegációkat illetően.# A '''''Delegations ''''' fülről váltson a '''''DCV (Domain Control Validation) ''''' fülre. Jelölje ki a megfelelő domaint, és a megjelenő DCV gomb segítségével indítsa el a DCV folyamatot. Válasszon metódust:
#* Az ''"Email"'' opcióval a tartomány öt lehetséges címe közül választható ki az, ami majd fogadja és kezeli az oda küldött e-maileket. Példánk esetében ez lehet az „admin@example.org”, „administrator@example.org”, „hostmaster@example.org”, „postmaster@example.org” vagy „webmaster@example.org”.
#* A ''"CNAME"'' opciót választva az SCM létrehoz egy DNS CNAME rekordot a választott domainhez, amit be kell tenni a DNS zónába. Javasolt egy külső névfeloldóval ellenőrizni, hogy a CNAME rekord a helyén van-e és kívülről valóban látható.
# Lépjen a '''''Settings → Organizations''''' elemre, és kattintson a megfelelő szervezeti sorra, majd a '''''Departments''''' gombbal jelenítse meg a listázási ablakot, és nyomja meg az '''''Add''''' gombot.
# Adja meg a kívánt ''"OU ="'' név összetevőt a ''Department Name'' mezőnél. A név többi része megegyezik a szervezetével.
# Válassza ki a '''''Client Certificate''''' fület, és tiltsa le a MRAO és a DRAO számára a Key Recovery kulcs-helyreállítást (''"Allow Key Recovery by Master Administrators"'' és ''"Allow Key Recovery by Department Administrators"''). A RAO-k számára már tiltva lesz, mivel az a SUNET által végzett szervezetbeállítás része volt.
# Az egyéb opciókkal nem kell most foglalkozni, mivel ezek később is beállíthatóak. A befejezéshez nyomja meg az '''''OK''''' gombot.
lapon az '''''Add''''' gombra. A meglévő adminisztrátorokat szerkesztheti is, ha kiválasztja, majd megnyomja az Edit gombot.
# Töltse ki a bejelentkezési adatokat (megfelelő felhasználói névvel), az e-mailt, az utónévet és a vezetéknevet. Javasoljuk, hogy hagyja üresen a többi kapcsolattartási információt, mivel erre nincs szükség.
# Válassza ki a ''"Your Institution"'' résznél az Identity Provider-ét (IdP), és töltse ki az admin ePPN-jét (''"SWAMID identity"'') az ''"IdP Person Id”''-ben, hogy az adminisztrátor be tudjon jelentkezni SWAMID-en keresztül, ha a SAML helyesen van beállítva.
# Az új rendszergazda számára jelszót kell megadni. Az első bejelentkezéskor meg kell azt változtatnia.
# Válassza ki a kívánt jogosultságokat a '''''Privileges''''' fül alatt. Ne jelölje be a ''"WS API use only"'' opciót!
Azt határozottan javasoljuk, hogy hozzon létre saját admin felhasználókat is, hogy képes legyen látni, ki mit csinált a rendszerben.
Úgy tűnik, hogy bizonyos privilégiumokat (társ-adminisztrátorok kezelése, DCV engedélyezése) jelenleg egyik RAO nem rendelhet hozzá a másikhoz. Ha ez előfordulna, írjon e-mailt az [mailto:ugyfelszolgalat@kifu.hu címreÜgyfélszolgálat emailcímére], hogy beállítsuk azokat.
=== Zárolt felhasználói fiók ===
Lezáródhat, ha többször rossz bejelentkezési információkat ad meg. Ezután egy "Helytelen bejelentkezési adatok, a fiók zárolva van, a jelszó lejárt vagy a forrás IP-je le van tiltva" üzenetet kap. üzenet, amikor megpróbál bejelentkezni, akkor is, ha immár a helyes jelszót használja. Ez akkor is így lesz, ha jelszavát megváltoztatta egy másik rendszergazda, aki erre egyébként jogosult. A lezárás feloldását csak egy MRAO jogosultságú adminisztrátor végezheti el, így jelezze az ilyen jellegű problémát az [mailto:ugyfelszolgalat@kifu.hu címenÜgyfélszolgálatnál].
== SSL (szerver) tanúsítványok ==
Amikor a tanúsítvány kiadásra kerül, annak státusza ''"Issued"'' lesz, és e-mailt kap erről az igénylő.
Ha szükséges, akkor is letöltheti a tanúsítványt, ha rákattint annak kijelöléséhez, és használja a '''''Details''''' gombot, majd a '''''Select''''' gombot a ''"Certificate download"'' jobb oldalán.
=== CSR generálására példák ===
'''Egy domain esetén'''
<syntaxhighlight line>
openssl req -new -newkey rsa:4096 -nodes \
-out domain_kifu_hu.csr \
-keyout domain_kifu_hu.key \
-subj "/C=HU/ST=Budapest/L=Budapest/O=KIFÜ/OU=IKT/CN=domain.kifu.hu"
</syntaxhighlight>
'''Több domain esetén'''
<syntaxhighlight line>
openssl req -new -newkey rsa:4096 -nodes \
-out domainX_kifu_hu.csr \
-keyout domainX_kifu_hu.key \
-subj "/C=HU/ST=Budapest/L=Budapest/O=KIFÜ/OU=IKT/CN=domain1.kifu.hu/CN=domain2.kifu.hu"
</syntaxhighlight>
'''Wildcard'''
<syntaxhighlight line>
openssl req -new -newkey rsa:4096 -nodes \
-out star_domain_kifu_hu.csr \
-keyout star_domain_kifu_hu.key \
-subj "/C=HU/ST=Budapest/L=Budapest/O=KIFÜ/OU=IKT/CN=*.domain1.kifu.hu/CN=*.domain2.kifu.hu"
</syntaxhighlight>
Ha csak lehet, kerüljük az emailcím használatát a subjectben. Ha valamiért mégis szerepeltetni kell, akkor vigyázni kell arra, hogy az emailcím domainje szerepeljen az adott Organization/Department levalidált domainjei között.
<span style="color: red;">''Figyelem: A Sectigo ellenőrzi, hogy a Subjectben megadott adatok egyeznek-e az SCM felületén szereplő szervezeti adatokkal! Azaz az ST tagot akkor fogadja el, ha a szervezeti adatoknál ki van töltve a megye; valamint az OU-t csak akkor, ha az Organization alatt van Department is létrehozva. Ez utóbbi esetben ráadásul a CSR-ben szereplő domain(ek) delegálva kell legyen(ek) az adott Departmenthez!</span>
=== Nem adminisztrátor jogosultságú igénylések engedélyezése ===
* ''Nem javasoljuk'' az ''"Automatically Approve Self Enrollment Requests"'' opció bejelölését! Legalább manuálisan jóvá kell hagyatni az ezen a módon érkező tanúsítványkéréseket!
* Érdemes lehet testreszabnia a választható SSL típusokat az igénylő űrlaphoz ('''''SSL types → Customize''''', jobb oldali rész), hogy megakadályozza a felhasználót abban, hogy olyan tanúsítványtípusokat is igényeljen, melyeket nem kíván engedélyezni a számára. Az SCM felületén továbbra is megőrizheti a választási lehetőséget (a fenti felület bal oldali részén).
=== EV tanúsítványok ===
Amennyiben nem feltétlenül szükséges, nem javasolt EV tanúsítványok használata. Ha mégis igényelnének, akkor első lépésben meg kell nyitni a '''''Settings''''' -> '''''Organizations''''' résznél a saját intézményt szerkesztésre, és ott az '''''EV Details" fülön ki kell tölteni a megadott mezőket:
[[Fájl:Sectigo EV Details.png|bélyegkép]]
Amennyiben nem szerkeszthetőek ezek a mezők, kérjük küldje el az adatokat az [mailto:ugyfelszolgalat@kifu.hu Ügyfélszolgálat] emailcímére, és a KIFÜ adminisztrátorai kitöltik azokat. Ezek után indítható az EV tanúsítvány igénylése.
== Személyes tanúsítványok ==
#* Csak akkor használja a "Generate ECC" elemet, ha ECC tanúsítványokat tesztel. Ha nem biztos benne, használja inkább az RSA-t.
#* Ha nem szerver-oldalon generált kulccsal szeretne igényelni, használja az "Upload CSR" opciót.
# Ha a CSR feltöltést választja, akkor először létre kell hoznia a kulcsot és a CSR-t helyileg, bármilyen szoftverrel, amelyet amúgy erre használ. OpenSSL esetén: </br><code>openssl req -new -newkey rsa:2048 -out usercert_request.pem -keyout userkey.pem -subj '/CN=Teszt'<br /br> chmod go = userkey.pem<br /br>
cat usercert_request.pem</code>
# Ha úgy dönt, hogy a tanúsítványt a szerver oldalon generálja, meg kell adnia a létrehozandó PKCS#12 fájl titkosításához használt jelszót.
# Rövid idő elteltével letöltheti a tanúsítványt. A formátum az alábbi választástól függ:
#* A ''"Generate RSA/ECC"'' funkcióval kap egy PKCS#12 fájlt certs.p12 névvel, ami tartalmazza a kulcsot és a tanúsítványt. Ezt importálhatja böngészőjébe a ''"Tanúsítvány importálása"'' opcióval.
#* Az ''"Upload CSR"'' funkcióval kap egy PEM-formátumú certs.pem fájlt, amely csak a tanúsítványt tartalmazza. Ha szükség van a böngészőbe importálásra, akkor saját magának kell létrehoznia egy PKCS#12 fájlt. Az OpenSSL-lel így lehet:</br>
<code>openssl pkcs12 -export -inkey userkey.pem -in certs.pem -out certs.p12</code>
# Ha az alábbi hibaüzenetet kapja miután a Submit gombra kattintott, és elfogadta a feltételeket: ''"Sectigo Certificate Manager enrollment request failed. Please contact your security administrator."'' annak az lehet az oka, hogy meghaladta a két érvényes tanúsítvány korlátját személyenként és tanúsítványprofilonként. Az új tanúsítvány kiállítása előtt vissza kell vonnia a két tanúsítvány közül legalább egyet. Ez hibaként lett leadva a Sectigo felé, remélhetőleg mielőbb javítják.
A SAML bejelentkezés engedélyezve van a KIFÜ SCM példányához, de az attribútumot manuálisan kell beállítania az Identity Providernél, mivel a metaadatokban lévő SCM entitásnak nincs előre definiált kategóriája.
A következő attribútumokat kell közzétenni az EntiyId-ben (https://cert-manager.com/shibboleth):
* eduPersonPrincipalName <nowiki>(urn:oid:1.3.6.1.4.1.5923.1.1.1.6)</nowiki>* mail <nowiki>(urn:oid:0.9.2342.19200300.100.1.3)</nowiki>* displayName <nowiki>(urn:oid:2.16.840.1.113730.3.1.241)</nowiki>* giveName <nowiki>(urna:oid:2.5.4.42)</nowiki>* sn <nowiki>(urn:oid:2.5.4.4)</nowiki>* schacHomeOrganization <nowiki>(urn:oid:1.3.6.1.4.1.25178.1.2.9)</nowiki>* eduPersonEntitlement <nowiki>(urn:oid:1.3.6.1.4.1.5923.1.1.1.7) </nowiki> az alábbi értékkel: <nowiki>urn:mace:terena.org:tcs:personal-user</nowiki>
=== Ellenőrizze, hogy az IdP megfelelően van-e konfigurálva ===
# Visszatérve az eredeti RAO-hoz, szerkessze az új admint, és állítsa be rá a „WS API use only” opciót.
# Ahhoz, hogy az API-hívásokat tanúsítványok kezelésére használhassuk, szerkeszteni kell a megfelelő ''Organization'' vagy ''Department'' objektumot, és az '''''SSL Certificate''''' lapon engedélyeznie kell a Web API jelölőnégyzetet. Meg kell adnia egy értéket a ''Secret key'' mezőhöz is.
=== ACME Windows ===
A certbot egyelőre béta verziójú, ennek figyelembevételével használja mindenki!
# Első lépésben létre kell hozni egy ACME (Automated Certificate Management Environment) felhasználót az SCM-ben. Ezt a '''''Settings → Organizations''''' részben tehető meg, a saját szervezet kiválasztása után fent megjelenik az '''''ACME Accounts''''' menüpont. A felugró menüben az '''''Add''''' gomb megnyomásával hozható létre új account. A szükséges adatok kitöltése után létrejön az account, és az utolsó kis képernyőn megjeleníti a felhasználáshoz szükséges adatokat. (''4. lépés'') Ezeket megfelelő helyre el kell menteni.
[[Fájl:Sectigo acme 01.png|bélyegkép|ACME]]
# Le kell tölteni a Windowsra a certbot klienst: https://dl.eff.org/certbot-beta-installer-win32.exe
# Fel kell installálni a klienst Windows 2016 vagy Windows 2019 szerverre. Az installálás során létrejön egy ütemezett feladat, ami naponta kétszer ellenőrzi, hogy szükséges-e a tanúsítvány megújítása, és ha igen, el is végzi.
# Negyedik lépésben be kell állítani a certbot klienst. El kell indítani a parancssort adminisztrátori jogosultsággal. A következő parancsot kell kiadni:
''certbot register --server https://acme.sectigo.com/v2/OV --eab-kid <your own KeY ID:> --eab-hmac-key <your own HMAC Key:> --email <an email address> ''
# A ''Key ID'' és a ''HMAC key'' a certbot account létrehozásakkor elmentett adatokból származnak. A certbot most már be van konfigurálva.
# Az ACME-n keresztüli tanúsítványigénylés:
''certbot certonly --domain <domainname> --server https://acme.sectigo.com/v2/OV''
# A cert a következő elérési úton lesz megtalálható: ''C:\Certbot\live\<domainname>''
# Fel kell installálni a tanúsítványt a szerverre (sajnos itt még nem sikerült kitalálni, hogy lehet ezt is automatizálni). Egy órába is beletelhet, mire megjelenik a tanúsítvány az SCM felületén. A státusza ''External'' lesz, az igénylőnél pedig ez jelenik meg: ''CN=Sectigo RSA Organization Validation Secure Server CA''
== Segítség ==
=== KIFÜ ügyfélszolgálat ===
Amennyiben ez a dokumentum nem tartalmazza a kérdésre a választ vagy megoldást a problémájára, kérjük írjon az alábbi email címre: [mailto: ugyfelszolgalat@kifu.huÜgyfélszolgálat]
=== Sectigo támogatás ===
=== Sectigo dokumentáció ===
A Sectigo teljes dokumentációja megtalálható az [https://support.sectigo.com/Com_KnowledgeProductPage?c=Sectigo_Certificate_Manager_SCM Admin_Guides&k=&lang= alábbi webhelyen].
Néhány javaslat:
* '''''"SCM - Sectigo® Certificate Manager Quick Start Guide"''''' - az SCM rendszer rövid bemutatása* '''''"SCM - Sectigo Certificate Manager Administrator’s Guide"''''' - lényegesen hosszabb, és alaposabb leírás a szolgáltatásról* '''''"SCM - Sectigo Certificate Manager REST API"''''' - a REST API leírása, automatizálási lehetőségek
=== GÉANT Trusted Certificate Service (TCS) ===
Az alábbi oldalon található a GÉANT leírása a tanúsítványszolgáltatásról (angol): https://www.geant.org/Services/Trust_identity_and_security/Pages/TCS.aspx
<br />TCS repository: https://wiki.geant.org/display/TCSNT/TCS+Repository == Visszaellenőrzés ==* [[TCSValidation | Validációs tapasztalatok]]* [[TCS_EV | Extended Validation]]
