38
szerkesztés
Módosítások
TCS
,nincs szerkesztési összefoglaló
== A KIFÜ tanúsítványszolgáltatás ==
'''Értesítések:'''
* <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>
* <span style="color: red;">''2021.03.01-től a Sectigo kiveszi a tanúsítványokból az utca megnevezésére és az irányítószámra vonatkozó információkat. Ez a már kiadott tanúsítványokat nem érinti, és nem is szükséges lecserélni azokat!''</span>
<span style="color: red;">[https://sectigo.com/resource-library/sectigo-to-remove-street-address-and-postal-code-from-certificates --->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á.
A DigiCert CertCentral-ban két alapvető felhasználófajta létezett: ''"Rendszergazdák"'', akik tanúsítványokat igényelhetnek/jóváhagyhatnak, validációs folyamatokat indíthatnak, megváltoztathatják a beállításokat és más adminisztrátori szintű dolgokat végezhetnek; valamint a ''"Felhasználók"'', akik csak tanúsítványokat kérhetnek (de mégis hitelesített felhasználói voltak a CertCentalnak, csakúgy, mint az adminisztrátorok).
Az SCM-ben alapvetően csak adminisztrátori felhasználók vannak. Ez azt jelenti, hogy elvileg nem lehetnek olyan felhasználók, akik bejelentkezhetnek az SCM-be, és csak tanúsítványokat kérhetnek. De az [[SSL tanúsítványokTCS#SSL_.28szerver.29_tan.C3.BAs.C3.ADtv.C3.A1nyok|SSL tanúsítványok]] részben kínálunk erre is megoldást.
=== Department (szervezeti egység) ===
számára, miközben "DRAO - SSL tanúsítványok" szerepkört is kaphat egy másik szervezethez tartozó szervezeti egységnél.
Az első rendszergazda, akit a KIFÜ ad meg az intézényhez, RAO jogosultsággal rendelkezik, és teljes hozzáférése van az Organization területén mindenhez, így a további adminisztrátorok (RAO-k és DRAO-k) beállítása is az ő feladata.
== Első lépések ==
Amikor létrejön egy szervezeti egység az SCM felületén, generálódik számára egy ún. ''Master key'', ezzel lesznek titkosítva az igényelt tanúsítványok. Ezt a kulcsot egy megfelelően biztonságos helyre le kell menteni. Az alábbi helyen található meg: '''''Settings → Encryption''''' fülön kell az intézményt kiválasztani. Itt kezdetben a státusz ''Not initialized''. Meg kell nyomni az '''''Initialize Encryption''''' gombot a fenti menüsoron. Ekkor feldobja a privát kulcsot, amit ki kell másolni és egy text fájlban gondosan, védetten eltárolni. A felugró ablakon ezek után '''''Done''''' billentyűt megnyomva rákérdez, hogy elmentettük-e a kulcsot, majd bezárja a felugró ablakot és az intézmény státuszát ''Public key is loaded'' állapotúra változtatja. Ezek után rendeltetésszerűen lehet használni a felületet.
== 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 bal oldali menüből a '''''Settings → Domains → Delegations''''' menüpontot, és nyomja meg az a zöld színű + (''Add gombot'') jelet. 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ó.<span style="color: red;">Ezt a metódust javasoljuk mindenki számára, stabilan, gyorsan működik a tapasztalataink alapján!</span>#* <span style="color: red;">FIGYELEM! Ez a metódus kivezetésre kerül 2021. 11.15-én!</span> A ''"HTTP / HTTPS" opció esetében egy bizonyos tartalommal létre kell hozni egy fájlt egy megadott névvel a domain névhez tartozó webkiszolgálón.
# Kövesse a kiválasztott módszerre vonatkozó utasításokat.
# Ha az érvényesítési folyamat rendben lezajlott, akkor a DCV lapon a Validation Status állapota Validated-re változik. A Delegations lapon a domain állapotának is ''"Validated"''-nek kell lennie. A plusz sor a "*" előtaggal bizonyos esetekben továbbra is ''"Not validated"'' státuszban van, de ez általában csak egy bizonyos ideig (pár órától egy napig) tart mire frissül.
# Most már minden készen áll arra, hogy ezt a domaint és az aldomainjeit tanúsítványkérésekhez használja. Nem kell megvárni, hogy a "*" előtagú domain is érvényes állapotba kerüljön.
<span style="color: red;">2021. decemberétől kizárólag subdomainre is elvégezhető a validáció!</span>
==== Metódus módosítása ====
Amennyiben nem megfelelő metódus lett kiválasztva, illetve valamiért nem működik a választottnál a validáció, van lehetőség változtatni. Ehhez a '''''Settings → Domains → DCV''''' fülön ki kell jelölni az érintett domaint, ekkor megjelenik a domainlista fölött a DCV gomb, és arra kattintva felugrik egy kis ablak. Itt lehet visszalépni illetve bizonyos fázisban resetelni a választott metódust.
==== Domain lejárat ====
A domainvalidáció 1 évig érvényes. A lejárat előtt figyelmeztetést küld a rendszer. Az újra validálás lehetősége pár nappal a lejárat előtt lesz éles. A lépések teljesen megegyeznek az első alkalommal történő validációs folyamattal.
=== Departments (Szervezeti egységek) ===
# 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 ===
felületén. Ehhez válassza a '''''Settings → Organizations''''' menüpontot, válassza ki a szervezetet, majd kattintson az '''''Edit''''' gombra. (Vagy ha csak egy szervezeti egységhez szeretné rendelni, akkor a szervezet kiválasztása után kattintson a '''''Department''''' gombra, válassza ki az egységet, és itt használja az '''''Edit''''' lehetőséget).
* Az '''''SSL certificate''''' lapon engedélyezze a ''"Self enrollment"'' opciót, és írjon egy titkos értéket az ''"Access Code"'' mezőbe, majd másolja ki a mező alatt található URL-t. Most elküldheti ezt az URL-t azoknak, akiket szeretné, hogy beléphessenek a nem adminisztrátorok számára fenntartott tanúsítvány igénylő felületre. Mint teszteléskor láthatja, hozzávetőlegesen ugyanazokat a mezőket tartalmazza ez az oldal, mint maga az SCM '''''"Add certificate"''''' része. Ne felejtse ellenőrizni az emailcímet amire elküldi a hozzáférést, illetve alakítson ki egy saját metódust a kérelmezők autentikálására!
* Amennyiben működik a SAML attribútum átadása a Sectigo felé (lásd a [[SAML konfigurációTCS#SAML_konfigur.C3.A1ci.C3.B3|SAML konfiguráció]] szekciót), akkor engedélyezheti a '''''"Self enrollment via SAML"''''' funkciót is, titkosítva tarthatja a hozzáférési kódot, és elküldheti a felhasználók számára a Token mező alatti URL-t. Ezután a SAML használatával hitelesíteniük kell magukat mielőtt a fentiekkel megegyező igénylő űrlapra belépnének. Mivel az e-mail cím most az IdP-től érkezik a SAML-en keresztül, biztos lehet abban, hogy helyes, de eldöntheti, hogy szükség lesz-e további autentikációra az igénylést megelőzően.
* ''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 ==
Az önkiszolgáló portál a következő címen található: https://cert-manager.com/customer/KIFU/idp/clientgeant
Ahhoz, hogy működjön a felhasználók számára, a következőket kell tenni:
* Helyesen be kell konfigurálni az IdP-t a Sectigo-hoz. Lásd a [[SAML konfigurációTCS#SAML_konfigur.C3.A1ci.C3.B3|SAML konfiguráció]] pontnál.
* Szerkessze a szervezeti objektumot, és állítsa az ''"Academic code (SCHAC Home Organization)"'' értéket ugyanarra az értékre, mint amit az IdP küld mint ''"schacHomeOrganization"''. Ez általában a fő domain, de ezt egyeztesse le az IdP rendszergazdáival.
#* 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 ===
Miután ellenőrizte, hogy az IdP helyesen van-e beállítva, folytathatja a SAML-hitelesítés használatának konfigurálását:
* Ahhoz, hogy használni lehessen a föderációs bejelentkezést az SCM portálon, be kell lépni az összes meglévő RAO és DRAO admin felhasználói fiókját tartalmazó oldalra ('''''Admins''''') és módosítani az '''''Identity provider''''' mezőt a saját intézményre, valamint az '''''IdP person ID''''' mezőt az ''admin ePPN'' (''eduPersonPrincipalName'') értékére.
* Az SSL-tanúsítványokról a "Self Enrollment via SAML" leírásnál olvashat fentebb a [[TCS#Nem_adminisztr.C3.A1tor_jogosults.C3.A1g.C3.BA_ig.C3.A9nyl.C3.A9sek_enged.C3.A9lyez.C3.A9se|Nem adminisztrátor jogosultságú igénylések engedélyezése]] részben.
== A REST API használata ==
# 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 ===
Ha a probléma jellege megkívánja, vegye fel a kapcsolatot a Sectigo Ügyfélszolgálatával a https://sectigo.com/support-ticket webhelyen a kérdésével/problémájával kapcsolatban. Eltérő utasítás hiányában válassza az "SCM Support" pontot a jegy okának. A leírásban szerepeljen az alábbi sor: ''"We are a KIFÜ member of the GEANT TCS service, using the https://cert-manager.com/customer/KIFU SCM SCM instance."''
Javasolt átnézni a Sectigo support oldalát is, illetve jól használható az ottani kereső is, a gyakori hibákra általában írnak egy külön cikket, mint pl. az [https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA03l000000noiG Anchor Certificate details are different]
=== 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]]
