A lap jelenlegi, 2025. szeptember 23., 15:12-kori változata

Tartalomjegyzék

1 Új Wiki oldal
- 1.1 A PRO-M tanúsítványszolgáltatás
2 HARICA tanúsítványszolgáltatás

Új Wiki oldal

Az új, frissített leírás EZEN A LINKEN található!

A PRO-M tanúsítványszolgáltatás

Értesítések: Elindult a szolgáltatás, ezen az emailcímen lehet érdeklődni a részletekről!

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.

HARICA tanúsítványszolgáltatás

A görög egyetemek szövetségének fejlesztésére épül az új TCS tanúsítványszolgáltató. Gyorsan haladnak a fejlesztéssel, de jelenleg még pár funkció – több szintű jogosultságkezelés, intézmények kezelése, ACME, stb. – fejlesztés alatt áll, és nem érhető el teljes funkcionalitásában. A HARICA rendszere az alábbi linken érhető el.

Regisztráció/belépés

Működik az eduID-s belépés, nincs szükség külön regisztrációra; az Academic login gombra kattintva érhető el. Előfeltételek leírása itt

HARICA login

Lehetséges egyéb e-mail címmel is regisztrálni a HARICA felületére, azonban ajánljuk a hivatali email cím használatát, mivel ez alapján az adott intézményhez is rendelődik a felhasználó, amennyiben az intézmény már benne van a rendszerben, és felvette magához a domaint, valamint a tanúsítványkérelem engedélyezésénél is ez alapján döntik el a kérelem jogosságát.
Belépés után, ha a tanúsítványigénylésen felül egyéb jogokat szeretnénk, akkor kötelező beállítani a kéttényezős hitelesítést. Ezt a jobb felső sarokban a saját nevünkre kattintva, a Profile menüpontnál lehet elérni. Jelenleg nem veszik figyelembe, hogy az eduID folyamatában is kéttényezős hitelesítés szerepel; ezt a problémát a GÉANT és az NREN-ek is jelezték a HARICA-nak. Valószínűleg engedélyezni fogják, hogy az intézmény kétlépcsős azonosítása esetén ne kelljen TOTP-t használni HARICA-nál.
Az e-mail cím domainje alapján automatikusan a PRO-M-hez vagy az intézményhez rendeli a felhasználót.
Csak ezután tudunk bárkinek bármiféle jogosultságot beállítani. Ilyen igényeket a ICT.ugyfelszolgalat@ugyfelszolgalat.gov.hu címre lehet küldeni.

SAML konfiguráció

Azoknak a TCS tagoknak, akik egyben identitásszolgáltatók is az eduGAIN-ben, a következő attribútumokat kell közzétenniük:

givenName (oid:2.5.4.42)
surname (oid:2.5.4.4)
mail (oid:0.9.2342.19200300.100.1.3)
edupersonTargetedID (oid:1.3.6.1.4.1.5923.1.1.1.10)

Közzétehető további attribútumok:

eduPersonPrimaryAffiliation (oid:1.3.6.1.4.1.5923.1.1.1.5)
eduPersonPrincipalName (kötelező az IGTF személyes tanúsítványokhoz) (oid:1.3.6.1.4.1.5923.1.1.1.6)
eduPersonEntitlement (szükséges az IGTF személyes tanúsítványokhoz) (oid:1.3.6.1.4.1.5923.1.1.1.7)

Ügyeljen arra, hogy csak a TCS-hez társított értékeket küldje el a HARICA SP-knek. Használja az „urn:mace:terena.org:tcs:personal-user” azonosítót az IGTF személyes tanúsítványok kiadásának engedélyezéséhez.

schacHomeOrganization (oid:1.3.6.1.4.1.25178.1.2.9)

A következő HARICA EntityID-knek kell attribútumot kiadni:

PRODUCTION:
- https://www.harica.gr/simplesamlphp/module.php/saml/sp/metadata.php/pki-grnet-sp
- Attribútum kiadás teszt: https://cm.harica.gr/loginsaml/test.php

Alternatív letöltési / megtekintési link az XML fájlhoz: https://met.refeds.org/met/entity/https%253A%252F%252Fwww.harica.gr%252Fsimplesamlphp%252Fmodule.php%252Fsaml%252Fsp%252Fmetadata.php%252Fpki-grnet-sp/?federation=grnet-federation

Az attribútum kiadás teszt elérhető a felületen a „View login information” gombbal is a felhasználói profil alatt.

Ismert problémák: A mail attribútumban több érték megadása jelenleg nem támogatott.

Jogosultsági szintek

Admin: Csak a saját intézményén belül tevékenykedik; más intézményekre nem lát rá. Az adott intézmény validálását (OV), akárcsak a domainjeiét (DV) intézheti. Jogosultságokat adhat az intézmény felhasználóinak (Admin és alatta lévő jogok). Tanúsítványt igényelhet. Az Admin mellé Approver jogosultság is beállítható.
Approver: El tudja fogadni a beküldött tanúsítványokat (kivéve a saját maga által beküldötteket). Tanúsítványt igényelhet.
User: Tanúsítványt igényelhet. Felhasználóként bárki beregisztrálhat a HARICA felületére – eduID mellett felhasználó/jelszó regisztráció is működik. Ha a regisztrációhoz használt e-mail cím domainje valamely intézmény felrögzített domainjei közé tartozik, akkor a felhasználót automatikusan hozzárendeli, és az intézmény Adminjai tudják kezelni. Jogosultságot csak Admin vagy Manager adhat, ha a User beállította a 2FA-t.

Jogosultságok beállítása

Egy adott intézmény (Enterprise) admin jogosultságú felhasználója képes az intézmény usereinek jogokat beállítani (amennyiben az adott felhasználó beállította a kétfaktoros hitelesítést). Ehhez a fejlécen található Enterprise → Admin menüpontra kell elnavigálni, ott a Users fülön a felhasználók listájából kiválasztani a megfelelőt. A felugró ablakban az Account info fülön lehet beállítani a megfelelő jogokat.

Domain menedzsment

Admin felhasználóként a felső menüsoron az Enterprise → Admin gombra kattintva az intézmény adatait tartalmazó ablakra kerülünk. A Domains fülön az intézményhez felvitt domainek listája található, itt meg lehet hosszabbítani a lejárt domainek validációját. A Validate Domain gombra kattintva:

DNS-record módszer: itt a felugró ablaknál megadott emailcímre küldik majd a kódot, amit be kell illeszteni a DNS recordba.
E-mail: a választott domain alap technikai e-mail címeire küldött ellenőrző levél alapján validálunk.

Új domain hozzáadásához vissza kell navigálni az Enterprises fülre, majd ott az intézményt kiválasztva, a megjelenő ablak jobb felső sarkában található földgömb ikonra kattintani. A letöltött CSV fájlt értelemszerűen kitöltve kell megadni az új domaineket. A felkínált minta fájlt kell használni, mert más formátum esetén hibát kapunk. Az admin saját emailcímére kap egy visszajelzést, hogy beküldött x db domaint a szervezetéhez. (HARICA Notification, Your request for x new Domain(s) in yourenterprise has been submitted.) A domainek elfogadásáról azonban nincs visszajelzés, kb 1 napon belül megjelennek a listában.

Tanúsítvány típusok

Az alábbi tanúsítványtípusok érhetőek el a PRO-m keretszerződés keretében:

Server Certificates (szerver tanúsítványok)

Mire jó?
Ez gondoskodik arról, hogy egy weboldal „biztonságos” legyen – vagyis titkosított kapcsolaton keresztül kommunikáljon (https://). A böngésző kis lakat ikonja is ezt jelzi.
Kinek van rá szüksége?
Weboldalak üzemeltetőinek, akik adatokat kezelnek (belépés, regisztráció, űrlapok, webshop). Cégek, iskolák, kutatóintézetek szerverei számára kötelező lehet.

Domain Validated (DV)
- Egyszerű domain-vizsgálaton alapuló SSL/TLS

- Gyors kiállítás, olcsóbb
Multi-domain (SAN)
- Több FQDN (Subject Alternative Name) egy tanúsítványban

- Költséghatékony több szolgáltatás védelmére
Wildcard
- Egy domain és összes aldomain (pl. *.példa.hu) védelme

- Praktikus dinamikusan létrejövő aldomain-ek esetén
Organization Validated (OV)
- Szervezeti validáció, tartalmazza a cég hivatalos adatait

- Erősebb bizalom a látogatók felé
IGTF
- Tudományos és kutatási infrastruktúrák számára interoperábilis tanúsítvány

- Követi az Interoperable Global Trust Federation szabványait

IGTF kliens tanúsítvány

Mire jó? Speciálisan tudományos számítástechnikai hálózatokban (GRID-ek) használják, ahol nagy számítási kapacitást igénylő kutatások zajlanak.
Kinek van rá szüksége? Tudósoknak, kutatóknak, akik nemzetközi számítási hálózatokhoz csatlakoznak (pl. CERN, bioinformatikai hálózatok, stb.).
Az itt leírtak teljesülése esetén válik elérhetővé.

Email (S/MIME tanúsítványok)

Mire jó?
Segít annak igazolásában, hogy az e-mailek valóban a megjelölt feladótól illetve szervezettől származnak (digitális aláírás), valamint hogy titkosítható legyen a tartalmuk, hogy illetéktelen ne olvashassa el.
Kinek van rá szüksége?
Olyan magánszemélyeknek vagy szervezeti dolgozóknak, akik bizalmas adatokat küldenek emailben – pl. jogászok, orvosok, informatikusok, közigazgatási dolgozók.

Email-only
S/MIME tanúsítvány csak e-mail aláírásra és titkosításra
- Tartalmazza az e-mail cím(eke)t
IV+OV – Hybrid
- Egyéni és szervezeti adatok egy tanúsítványban

- Hasznos nagyvállalati környezetben

Az alábbi típusok az oldalon helyben megjelölt díjazásért cserében igényelhetők, bankkártyával fizetve az igénylési folyamat végén:

eSignatures (elektronikus aláírások)

Mire jó?
Ezzel a tanúsítvánnyal hiteles elektronikus aláírást lehet létrehozni – például hivatalos dokumentumok, szerződések aláírására, ugyanúgy, mintha kézzel lenne aláírva, papíron.
Kinek van rá szüksége?
Magánszemélyeknek, cégek munkatársainak vagy hivatalos ügyintézőknek, akik dokumentumokat írnak alá elektronikusan.

Remote Qualified eSignature
Jogilag hitelesített, eszközfüggetlen minősített aláírás. Használható:
- Szerződések (értékesítés, munka, bérlet, biztosítás stb.)

- Tranzakciók (e‑kereskedelem, online bankolás stb.)

- Közigazgatási ügyintézés (adóbevallás, anyakönyvi kivonat kérése stb.)
Qualified eSignature in cryptographic device (token)
Minősített aláírás USB‑tokenen vagy smartcardon
- Ugyanazok a felhasználási területek, mint a Remote Qualified eSignature-nél
Advanced eSignature (legacy Class B)
Haladó elektronikus aláírási tanúsítvány korábbi (Class B) szabvány szerint
- Dokumentumok digitális aláírására, jogi elismeréssel

eSeals (elektronikus pecsétek)

Mire jó?
Ez nem egy személyhez, hanem egy szervezethez kapcsolódik. Olyan, mint egy pecsét, amit automatikusan rá lehet tenni digitális dokumentumokra – például számlákra, igazolásokra.
Kinek van rá szüksége?
Cégeknek, intézményeknek, akik automatizált módon „hitelesítenék” dokumentumaikat (pl. e-számlák, gép által generált igazolások).

Remote Qualified eSeal
Hagyományos pecséttel jogilag egyenértékű, eszközfüggetlen
- CertManager vagy API felületen keresztül, bármilyen eszközről használható

- Tartalmazza a szervezet hivatalos adatait

- Havi 500 ingyenes aláírás; többlet aláírás díjköteles (support@harica.gr)
Advanced eSeal
Haladó pecsét tanúsítvány jogilag kötelező dokumentumokhoz
- Tartalmazza a szervezeti adatokat és aláírási logokat

Code Signing (kódaláírás)

Mire jó?
Ezzel tanúsítható, hogy egy program vagy alkalmazás valóban attól származik, aki kiadta, és nem módosították utólag.
Kinek van rá szüksége?
Szoftverfejlesztőknek és cégeknek, akik alkalmazásokat, programokat készítenek és szeretnék, hogy azt biztonságosnak ismerje fel a rendszer (Windows, macOS, stb.).

IV – Individuals/Sole Proprietorships
Alkalmazások, driverek, futtatható állományok digitális aláírása
- Tartalmazza a természetes személy Publisher adatait
OV – Organizations
Szoftver- és kódaláírás szervezetek részére
- Tartalmazza a jogi személy adatait
EV – Extended Validation
- Azonnali reputáció Microsoft Windows rendszeren

- Részvétel a Windows Hardware Compatibility programban

- Hivatalos cégnyilvántartási adatok feltüntetésével

Email (S/MIME tanúsítványok)

IV – Individuals/Sole Proprietorships
Magánszemélyi tanúsítvány e-mail aláírásra/titkosításra
- E-mail cím és természetes személy adatok
OV – Organizations
Szervezeti e-mail tanúsítvány
- E-mail cím és céginformációk

Client Authentication (ügyfél hitelesítés)

Mire jó?
Ez egyfajta digitális igazolvány, amivel egy rendszer azonosítani tudja a felhasználót. Például belépéshez használható egy webes portálra.
Kinek van rá szüksége?
Egyetemek, intézmények dolgozói vagy diákjai, ha olyan belépési rendszert használnak, ami tanúsítványalapú azonosítást vár el.

IV (User)
Felhasználói hitelesítés tanúsítvány. Tartalmazhatja:
- Természetes személy adatait

- Kapcsolódó szervezet adatait

- E-mail cím(eke)t

- Egy vagy több domaint
OV (Machine)
Gép- vagy szolgáltatáshitelesítő tanúsítvány
- Tartalmazza a szervezet adatait, e-mailt és doméneket

További információ A részletes leírások és megrendelési lehetőségek elérhetők a HARICA hivatalos weboldalán: https://www.harica.gr/certificates.

Tanúsítvány igénylés

Minden tanúsítvány igénylés a rendszer bal oldali menüjében található menüpontokkal történik. A tanúsítványkérelmek létrehozásához rendelkeznie kell egy felhasználóval a rendszerben (lásd fent), de a felhasználónak nem kell szerepkörrel rendelkeznie. Felhasználó saját kérését nem hagyhatja jóvá, még akkor sem ha adminisztrátor. Ezt egy másik Szervezeti jóváhagyó (Approver) szerepkörrel rendelkező felhasználónak kell megtennie. Ezzel szemben, ha administrátor fogja jóváhagyni a tanúsítványt, akkor egy másik felhasználónak kell igényelnie.

Figyelem Approver-eknek: Tanúsítványigénylést bárki be tud küldeni, akár másik intézménytől is, ezért érdemes alaposan ellenőrizni az igénylést, beleértve az igénylő személyét is, hogy valóban jogosult a cert kiadására!

Szerver tanúsítványok

Használja a Certificate Requests → Server útvonalat.

Az első oldalon adjon meg egy opcionális becenevet a tanúsítványnak, majd adjon hozzá egy vagy több domain nevet, amely szerepelni fog a tanúsítványban. Az első hozzáadott név a tanúsítvány CN-je lesz, és az összes hozzáadott név SAN DNS-bejegyzésként jelenik meg a tanúsítványban. Ha nem törli a jelölést a név alatti jelölőnégyzetből, akkor a rendszer hozzáad egy további nevet a www előtaggal SAN DNS-ként.

A becenév csak a kérelmező számára jelenik meg a tanúsítvány listákon. A jóváhagyók/adminisztrátorok nem fogják látni. Javasoljuk, hogy hagyja üresen, mivel ebben az esetben a CN (az első beírt domainnév) jelenik meg.

CAA rekord megléte a domain zónájában nem kötelező, csak ha már létezik más CA-hoz tartozó CAA. Ez esetben megjeleníti milyen CAA-kat szeretne látni:

CAA 0 issue "harica.gr"
CAA 0 issuewild "harica.gr"

A később feltöltött CSR-ből nem veszik fel a tanúsítványhoz tartozó neveket. Ebben a szakaszban hozzá kell adnia őket. Ez a jövőben változhat.

Jelenleg legfeljebb 100 domain név adható meg (és feltételezzük, hogy ez összesen 200-t jelent, ha elfogadja az összes www-előtt nevet is).

Wildcard tanúsítvány a szokásos eljárással igényelhető. Például a domainnév mezőben a *.example.com formában adjuk meg. Ilyenkor az example.com-t nem kell a kérésbe belefoglalni.

A következő oldalon válassza ki a tanúsítvány típusát:

DV – mindig elérhető, amint a domain validálása megtörtént, és csak a domain információkat tartalmazza. Ez a típusú tanúsítvány hasonlít leginkább arra tanusítványra, amelyet a Let's Encrypt-től lehet kapni.
OV – a Szervezet érvényesítése után érhető el. Ez ugyanaz a típusú tanúsítvány, amelyet korábban a Sectigo-tól lehetett kapni.
EV – Ne válassza a „Vállalkozásoknak vagy szervezeteknek (EV)” lehetőséget, mert ez a fajta tanusítvány NEM része a HARICA TCS ajánlatának, mivel már nem látjuk értékét ennek a tanúsítványtípusnak az alapértelmezett opcióként való támogatásában. Ezeket (EV TLS) és más típusú tanúsítványokat (kódaláírás, minősített elektronikus aláírások/bélyegzők, QWAC-ok) és távoli aláírási szolgáltatásokat egyedileg is meg lehet vásárolni a HARICA-tól, ha speciális felhasználási eseteknél szükség van rá.

Ha a DV vagy OV opció a “free” helyett “from AMOUNT€ year” felirattal jelenik meg, ne folytassa. A valószínű okok a következők:

Elírást vétett, és olyan domain nevet adott meg, amely nem tartozik az Ön Szervezetéhez. Kezdje elölről, és ellenőrizze, hogy a nevek helyesek-e.
Olyan domaint próbált használni, amelyet még nem adott hozzá és nem validált a rendszerben. (Lásd fent: További domainek hozzáadása) Erősítse meg a típusválasztást, majd erősítse meg az információkat, és fogadja el a használati feltételeket stb.

A Submit Request lépésben használja a CSR beküldése manuálisan lehetőséget, hogy beillessze a CSR-t. Fogadja el újra a használati feltételeket stb., és küldje el a kérelmet.

CSR generálás a következő paranccsal lehetséges: (4096 bites RSA kulcs létrehozásához)

openssl req -new -newkey rsa:4096 -nodes \ -out peldadomain.hu.csr \ -keyout peldadomain.hu.key \ -subj "/C=HU/L=Budapest/O=Pro-M Zrt/CN=peldadomain.hu"

Azonban a -subj utáni résznek nincs jelentősége, mert:

DV esetén nem lesz értelme, mert csak a CN-t tartalmazza,
OV esetében pedig a Szervezet - annak létrehozásakor megadott - C=HU,L=Budapest,O=Pro-M Zrt. értékeit fogja felvenni.

Ha az “Auto-generate CSR” módot választjuk, akkor a privát kulcs közvetlenül jön létre, és a rendszer automatikusan generálja a CSR-t. Ekkor a privát kulcsot védő, legalább 8 karakteres jelszó megadása szükséges, és a privát kulcs letöltésének megtörténtét is meg kell erősíteni. Annak pótlására nincs lehetőség a későbbiekben.

2025-01-16-án felfedezett BUG: A következő hibaüzenet jelenhet meg: ”You have already used this key before. If your private key gets compromised, we will have to revoke ALL CERTIFICATES associated with this key.“ ha van egy üres sor a CSR előtt a mezőben (és esetleg más szintaktikai hibák esetén is). Ne folytassa, hanem ellenőrizze, hogy a CSR formátuma megfelelő-e, és küldje be újra. Természetesen akkor is ezt az üzenetet fogja kapni, ha újra megpróbál egy kulcsot használni.

Tanúsítványkérelme mostantól a függőben lévő (Pending) tanúsítványok között lesz felsorolva, amíg az egyik Szervezetéhez tartozó jóváhagyó jóvá nem hagyja azt. A függőben lévő jóváhagyásról e-mailt küld a rendszer az intézyményi értesítési aliasra.

Ha egy Szervezetéhez tartozó jóváhagyó jóváhagyta a tanúsítványt, a listában a tanúsítványtól jobbra található letöltési nyíl segítségével töltheti le.

IGTF (aka Grid, eScience) Server Certificates - IGTF szerver tanúsítványok

Előfeltételek

IGTF OV szerver tanúsítvány igényléséhez a szervezethez be kell kapcsolni az IGTF tanúsítványigénylés engedélyezését. Ezt a szervezet információi oldalon a jobb felső sarokban lévő Tags gombon megjelenő ablakban lehet megtenni. (Admin szintű jogosultság szükséges)
Megtörtént az Organization Validation eljárás.

Igénylés Szervertanúsítvány igénylésekor a második oldalon (a nevek megadása után) válassza az OV típust. Erősítse meg a következő oldalon. Ezután a „Szervezeti adatok” oldalon jelölje be az „IGTF eScience digitális tanúsítvány igénylése” jelölőnégyzetet. Ahogy ott is szerepel, az „L” és „O” névkomponensek szükség szerint ASCII karakterekké alakulnak.

IGTF (aka Grid, eScience) Client Auth Certificates – IGTF kliens auth tanúsítványok

Előfeltételek

Be kell kapcsolni az IGTF tanúsítványigénylés engedélyezését. Ezt a szervezet információi oldalon a jobb felső sarokban lévő Tags gombon megjelenő ablakban lehet megtenni. (admin role szükséges)
Konfigurálja az IdP-t, hogy a szükséges attribútumokat kiadja a HARICA-nak. Lásd az alábbi „SAML konfiguráció” részt. :?:

Igénylés

Jelentkezzen be a https://cm.harica.gr/ címen az Academic Login és az IdP-nél használt felhasználónevével. Ehhez a működéshez Academic Login szükséges.
A bal szélen található menüben válassza az IGTF klienshitelesítés lehetőséget. Ne válassza a Klienshitelesítés lehetőséget (ami a szerződésünkben nem szereplő, nem IGTF hitelesítési tanúsítványokhoz tartozik).
Válassza a GÉANT személyes hitelesítést tanúsítványtípusként, és erősítse meg ezt újra a következő oldalon.
Fogadja el a feltételeket, és folytassa a Kérés elküldése gombbal.
Használja a Tanúsítvány regisztrálása gombot a Kész tanúsítványok listában.
Használja a Tanúsítvány generálása lehetőséget a következő oldalon, és győződjön meg arról, hogy olyan jelszót választ, amelyre később emlékezni fog. Jelölje be a „Megértettem…” jelölőnégyzetet, és folytassa a Tanúsítvány regisztrálása gombbal.
Használja a Letöltés gombot a Tanúsítvány beszerzése oldalon a kulcsot és a tanúsítványt tartalmazó PKCS#12 fájl mentéséhez.
Importálja a PKCS#12 fájlt oda, ahol szüksége van rá.

A kiemelt felhasználók dönthetnek úgy is, hogy manuálisan küldik el a CSR-t (miután korábban generáltak egy kulcsot, és szükség szerint kombinálják a kulcsot és a letöltött tanúsítványt).

ACME / Certbot használata

Ez a funkció jelenleg még általunk is tesztelés alatt áll, utána feltöltjük magyar nyelvű leírással ezt a részt is. Addig is angol nyelven az alábbi leírások érhetőek el:

Értesítések e-mailben

Értesítések lejáró S/MIME tanúsítványok esetében

Terv alatt álló funkció:

Egyedi tanúsítványigénylések esetén a rendszer automatikusan lejárati értesítést küld a CertManager portálról, a tanúsítványban szereplő e-mail címre, a lejárat előtt 30, 15, 5 és 1 nappal.

Tömeges (bulk) igénylések esetén a felhasználók egyetlen értesítést kapnak 30 nappal a lejárat előtt, közvetlenül a tanúsítványkiadótól (CA).

A tanúsítvány lejáratáról szóló e-mail az alábbihoz hasonló:

A xxxxxxxxxxxx sorszámú tanúsítvány, amely az alábbi entitás részére került kiadásra:
E=xxxxx@auth.gr, CN=Aristotle University of Thessaloniki, O=Aristotle University of Thessaloniki, L=Thessaloniki, C=GR,
és amelyet az alábbi tanúsítványkiadó bocsátott ki:
CN=HARICA S/MIME RSA SubCA R3, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR,
lejár: 2025-05-14 10:14:45+03:00.

Amint a tömeges kérésekkel kiadott S/MIME tanúsítványok is megjelennek a "S/MIME Certificates" fülön, az értesítési rendszer ezekre is alkalmazni fogja a fenti figyelmeztetési időpontokat.

Szervezeti események

Az Organization felvételekor megadott emailcím értesítést kap:

tanúsítvány igénylés érkezése
tanúsítványigénylés elfogadása
tanúsítvány visszavonása
domain validálása

Leírások angol nyelven

Segítség

PRO-M ügyfélszolgálat

Amennyiben ez a dokumentum nem tartalmazza a kérdésre a választ vagy megoldást a problémájára, az alábbi oldalon keresztül jelezhet nekünk: PRO-M Ügyfélszolgálat

„TCS” változatai közötti eltérés

A lap jelenlegi, 2025. szeptember 23., 15:12-kori változata

Tartalomjegyzék

Új Wiki oldal

A PRO-M tanúsítványszolgáltatás

HARICA tanúsítványszolgáltatás

Regisztráció/belépés

SAML konfiguráció

Jogosultsági szintek

Jogosultságok beállítása

Domain menedzsment

Tanúsítvány típusok

Server Certificates (szerver tanúsítványok)

IGTF kliens tanúsítvány

Email (S/MIME tanúsítványok)

eSignatures (elektronikus aláírások)

eSeals (elektronikus pecsétek)

Code Signing (kódaláírás)

Email (S/MIME tanúsítványok)

Client Authentication (ügyfél hitelesítés)

Tanúsítvány igénylés

Szerver tanúsítványok

IGTF (aka Grid, eScience) Server Certificates - IGTF szerver tanúsítványok

IGTF (aka Grid, eScience) Client Auth Certificates – IGTF kliens auth tanúsítványok

ACME / Certbot használata

Értesítések e-mailben

Értesítések lejáró S/MIME tanúsítványok esetében

Szervezeti események

Leírások angol nyelven

Segítség

PRO-M ügyfélszolgálat

Navigációs menü

Személyes eszközök

Névterek

Változatok

Nézetek

Több

Keresés

Navigáció

Eszközök

@@ 1. sor: / 1. sor: @@
-== A KIFÜ tanúsítványszolgáltatás ==
+= Új Wiki oldal =
+* <span style="color: red;">'''Az új, frissített leírás [https://help.edu.hu/books/tanusitvanyszolgaltatas/page/pro-m-tanusitvanyszolgaltatas EZEN A LINKEN] található!'''</span>
+---------------------------------------------------------------------
+---------------------------------------------------------------------
+== A PRO-M 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>
+Elindult a szolgáltatás, [mailto:ICT.ugyfelszolgalat@ugyfelszolgalat.gov.hu ezen az emailcímen] lehet érdeklődni a részletekről!
-<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.
-A felület az alábbi linken érhető el: https://cert-manager.com/customer/KIFU
+= HARICA tanúsítványszolgáltatás =
-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 [http://www.gunet.gr/ görög egyetemek szövetségének] fejlesztésére épül az új TCS tanúsítványszolgáltató. Gyorsan haladnak a fejlesztéssel, de jelenleg még pár funkció – több szintű jogosultságkezelés, intézmények kezelése, ACME, stb. – fejlesztés alatt áll, és nem érhető el teljes funkcionalitásában. A HARICA rendszere az alábbi '''[https://cm.harica.gr/ linken]''' érhető el.
+== Regisztráció/belépés ==
+# Működik az eduID-s belépés, nincs szükség külön regisztrációra; az '''Academic login''' gombra kattintva érhető el. Előfeltételek leírása [[#SAML_konfigur.C3.A1ci.C3.B3|itt]]
+[[Fájl:Harica-login.png|bélyegkép|HARICA login]]
+# Lehetséges egyéb e-mail címmel is regisztrálni a HARICA felületére, azonban ajánljuk a hivatali email cím használatát, mivel ez alapján az adott intézményhez is rendelődik a felhasználó, amennyiben az intézmény már benne van a rendszerben, és felvette magához a domaint, valamint a tanúsítványkérelem engedélyezésénél is ez alapján döntik el a kérelem jogosságát.
+# Belépés után, ha a tanúsítványigénylésen felül egyéb jogokat szeretnénk, akkor kötelező beállítani a kéttényezős hitelesítést. Ezt a jobb felső sarokban a saját nevünkre kattintva, a '''Profile''' menüpontnál lehet elérni. Jelenleg nem veszik figyelembe, hogy az eduID folyamatában is kéttényezős hitelesítés szerepel; ezt a problémát a GÉANT és az NREN-ek is jelezték a HARICA-nak. Valószínűleg engedélyezni fogják, hogy az intézmény kétlépcsős azonosítása esetén ne kelljen TOTP-t használni HARICA-nál.
+# Az e-mail cím domainje alapján automatikusan a PRO-M-hez vagy az intézményhez rendeli a felhasználót.
+# Csak ezután tudunk bárkinek bármiféle jogosultságot beállítani. Ilyen igényeket a [mailto:ICT.ugyfelszolgalat@ugyfelszolgalat.gov.hu ICT.ugyfelszolgalat@ugyfelszolgalat.gov.hu] címre lehet küldeni.
-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 [[:TCS#Valid.C3.A1ci.C3.B3s_folyamatok|validálja]].
+=== SAML konfiguráció ===
-== Igényelhető tanúsítványok ==
+Azoknak a TCS tagoknak, akik egyben identitásszolgáltatók is az eduGAIN-ben, a következő attribútumokat kell közzétenniük:
-* [[TCSCertTypes | Igényelhető tanúsítvány típusok]]
+* givenName (oid:2.5.4.42)
+* surname (oid:2.5.4.4)
+* mail (oid:0.9.2342.19200300.100.1.3)
+* edupersonTargetedID (oid:1.3.6.1.4.1.5923.1.1.1.10)
-== Szolgáltatás feltételei ==
+Közzétehető további attribútumok:
-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 Ügyfélszolgálat emailcímére] vagy hívja a +3614503070 telefonszámot.
+* eduPersonPrimaryAffiliation (oid:1.3.6.1.4.1.5923.1.1.1.5)
+* eduPersonPrincipalName (kötelező az IGTF személyes tanúsítványokhoz) (oid:1.3.6.1.4.1.5923.1.1.1.6)
+* eduPersonEntitlement (szükséges az IGTF személyes tanúsítványokhoz) (oid:1.3.6.1.4.1.5923.1.1.1.7)
+ Ügyeljen arra, hogy csak a TCS-hez társított értékeket küldje el a HARICA SP-knek. Használja az „urn:mace:terena.org:tcs:personal-user” azonosítót az IGTF személyes tanúsítványok kiadásának engedélyezéséhez.
+* schacHomeOrganization (oid:1.3.6.1.4.1.25178.1.2.9)
-== Különbségek az előző (DigiCertes) szolgáltatóhoz képest ==
+A következő HARICA EntityID-knek kell attribútumot kiadni:
-=== Új szolgáltató, új webes felület ===
+* '''PRODUCTION:'''
+** https://www.harica.gr/simplesamlphp/module.php/saml/sp/metadata.php/pki-grnet-sp
+** Attribútum kiadás teszt: https://cm.harica.gr/loginsaml/test.php
-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.
+Alternatív letöltési / megtekintési link az XML fájlhoz: https://met.refeds.org/met/entity/https%253A%252F%252Fwww.harica.gr%252Fsimplesamlphp%252Fmodule.php%252Fsaml%252Fsp%252Fmetadata.php%252Fpki-grnet-sp/?federation=grnet-federation
-<syntaxhighlight line>
+Az attribútum kiadás teszt elérhető a felületen a „View login information” gombbal is a felhasználói profil alatt.
-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 ===
+'''Ismert problémák:''' A mail attribútumban több érték megadása jelenleg nem támogatott.
-Az SCM-ben nem működik a divízió koncepciója, úgy ahogyan az a DigiCert CertCentralban volt.
+== Jogosultsági szintek ==
-* 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á.
+* '''Admin:''' Csak a saját intézményén belül tevékenykedik; más intézményekre nem lát rá. Az adott intézmény validálását (OV), akárcsak a domainjeiét (DV) intézheti. Jogosultságokat adhat az intézmény felhasználóinak (Admin és alatta lévő jogok). Tanúsítványt igényelhet. Az Admin mellé Approver jogosultság is beállítható.
-* 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 Szervezet-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.
+* '''Approver:''' El tudja fogadni a beküldött tanúsítványokat (kivéve a saját maga által beküldötteket). Tanúsítványt igényelhet.
-* Az Organization alatt lehetőség van kisebb szervezeti egységeket, Departmenteket létrehozni, és akár saját adminisztrátorokat rendelni hozzá.
+* '''User:''' Tanúsítványt igényelhet. Felhasználóként bárki beregisztrálhat a HARICA felületére – eduID mellett felhasználó/jelszó regisztráció is működik. Ha a regisztrációhoz használt e-mail cím domainje valamely intézmény felrögzített domainjei közé tartozik, akkor a felhasználót automatikusan hozzárendeli, és az intézmény Adminjai tudják kezelni. Jogosultságot csak Admin vagy Manager adhat, ha a User beállította a 2FA-t.
-=== Nincs User-szintű felhasználó ===
+== Jogosultságok beállítása ==
-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).
+Egy adott intézmény (Enterprise) admin jogosultságú felhasználója képes az intézmény usereinek jogokat beállítani (amennyiben az adott felhasználó beállította a kétfaktoros hitelesítést). Ehhez a fejlécen található '''Enterprise → Admin''' menüpontra kell elnavigálni, ott a '''Users''' fülön a felhasználók listájából kiválasztani a megfelelőt. A felugró ablakban az '''Account info''' fülön lehet beállítani a megfelelő jogokat.
-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 [[TCS#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) ===
+== Domain menedzsment ==
+Admin felhasználóként a felső menüsoron az '''Enterprise → Admin''' gombra kattintva az intézmény adatait tartalmazó ablakra kerülünk. A '''Domains''' fülön az intézményhez felvitt domainek listája található, itt meg lehet hosszabbítani a lejárt domainek validációját. A '''Validate Domain''' gombra kattintva:
+* DNS-record módszer: itt a felugró ablaknál megadott emailcímre küldik majd a kódot, amit be kell illeszteni a DNS recordba.
+* E-mail: a választott domain alap technikai e-mail címeire küldött ellenőrző levél alapján validálunk.
+Új domain hozzáadásához vissza kell navigálni az '''Enterprises''' fülre, majd ott az intézményt kiválasztva, a megjelenő ablak jobb felső sarkában található földgömb ikonra kattintani. A letöltött CSV fájlt értelemszerűen kitöltve kell megadni az új domaineket. A felkínált minta fájlt kell használni, mert más formátum esetén hibát kapunk.
+Az admin saját emailcímére kap egy visszajelzést, hogy beküldött x db domaint a szervezetéhez. (HARICA Notification, ''Your request for x new Domain(s) in yourenterprise has been submitted.'') A domainek elfogadásáról azonban nincs visszajelzés, kb 1 napon belül megjelennek a listában.
-Az SCM lehetővé teszi a szervezetek alatt kisebb szervezeti egységek - departmentek - létrehozását. Csakúgy, mint a szervezet neve, ami belekerül a tanúsítvány ''"O ="'' objektumba, az egység neve is belekerül a tanúsítvány ''"OU ="'' objektumába. A departmentek kétféle módon használhatók:
+== Tanúsítvány típusok ==
-* Egyszerű eszközként a tanúsítványok rendezéséhez és a helyes ''"OU ="'' objektum beállításához, de a jóváhagyást továbbra is a szervezet adminisztrátorai fogják végrehajtani.
+  Az alábbi tanúsítványtípusok érhetőek el a PRO-m keretszerződés keretében:
-* A tanúsítványok jóváhagyásának átruházásával a Department adminisztrátorainak. A legtöbb  esetben ez összekapcsolódik egy aldomain (vagy egy teljesen más domain) regisztrálásával, és annak használatára korlátozza a szervezeti egységet.
-=== MRAO, RAO, DRAO! ===
+==== Server Certificates (szerver tanúsítványok) ====
-Az adminisztrátoroknak három szintje létezik az SCM-ben, és mindegyiket RAO-val (Registration Authority Officer) jelölik:
+'''''Mire jó?'''''<br>
-* '''MRAO:''' a "superuser szint", a KIFÜ munkatársai látják el ezt a szerepet, amely képes kezelni minden szervezetet, osztályt, domaint, tanúsítványt, rendszergazdát stb.
+Ez gondoskodik arról, hogy egy weboldal „biztonságos” legyen – vagyis titkosított kapcsolaton keresztül kommunikáljon (''https://''). A böngésző kis lakat ikonja is ezt jelzi.<br>
-* '''RAO:''' szervezeti adminisztrációs szint, egy szervezet működtetéséhez, valamint a szervezethez tartozó osztályok, tartományok, tanúsítványok, adminok stb. kezeléséhez
+'''''Kinek van rá szüksége?'''''  <br>
-* '''DRAO:''' a szervezet alatt lévő Department rész működtetésének adminisztrátori szintje, az ehhez tartozó tartományok, tanúsítványok, adminok stb. kezelése
+Weboldalak üzemeltetőinek, akik adatokat kezelnek (belépés, regisztráció, űrlapok, webshop). Cégek, iskolák, kutatóintézetek szerverei számára kötelező lehet.
-Ennél kicsit összetettebben is szabályozható a rendszer: a RAO tartozhat egy vagy több szervezethez, a DRAO egy vagy több részleghez. Lehetőség van azt is beállítani, hogy csak SSL tanúsítványok, ügyfél tanúsítványok és/vagy kód aláírásokhoz szükséges tanúsítványokat legyen joga intézni. Így lehet egy adminisztrátor "RAO - SSL tanúsítványok" és "RAO - kliens tanúsítványok" jogkörökkel is egy-egy szervezet
+* ''Domain Validated (DV)''
-számára, miközben "DRAO - SSL tanúsítványok" szerepkört is kaphat egy másik szervezethez tartozó szervezeti egységnél.
+*:- Egyszerű domain-vizsgálaton alapuló SSL/TLS
-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.
+*:- Gyors kiállítás, olcsóbb
+* ''Multi-domain (SAN)''
+*:- Több FQDN (Subject Alternative Name) egy tanúsítványban
+*:- Költséghatékony több szolgáltatás védelmére
+* ''Wildcard''
+*:- Egy domain és összes aldomain (pl. *.példa.hu) védelme
+*:- Praktikus dinamikusan létrejövő aldomain-ek esetén
+* ''Organization Validated (OV)''
+*:- Szervezeti validáció, tartalmazza a cég hivatalos adatait
+*:- Erősebb bizalom a látogatók felé
+* ''IGTF''
+*:- Tudományos és kutatási infrastruktúrák számára interoperábilis tanúsítvány
+*:- Követi az Interoperable Global Trust Federation szabványait
-== Első lépések ==
+==== IGTF kliens tanúsítvány ====
-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.
+'''''Mire jó?'''''
+Speciálisan tudományos számítástechnikai hálózatokban (GRID-ek) használják, ahol nagy számítási kapacitást igénylő kutatások zajlanak.<br>
+'''''Kinek van rá szüksége?'''''
+Tudósoknak, kutatóknak, akik nemzetközi számítási hálózatokhoz csatlakoznak (pl. CERN, bioinformatikai hálózatok, stb.).<br>
+[[#SAML_konfigur.C3.A1ci.C3.B3|Az itt leírtak teljesülése esetén válik elérhetővé.]]
-== Validációs folyamatok ==
+==== Email (S/MIME tanúsítványok) ====
-=== 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.
+'''''Mire jó?'''''  <br>
+Segít annak igazolásában, hogy az e-mailek valóban a megjelölt feladótól illetve szervezettől származnak (digitális aláírás), valamint hogy titkosítható legyen a tartalmuk, hogy illetéktelen ne olvashassa el.<br>
+'''''Kinek van rá szüksége?'''''  <br>
+Olyan magánszemélyeknek vagy szervezeti dolgozóknak, akik bizalmas adatokat küldenek emailben – pl. jogászok, orvosok, informatikusok, közigazgatási dolgozók.
-=== Domain validáció ===
+* ''Email-only''<br>S/MIME tanúsítvány csak e-mail aláírásra és titkosításra
+*:- Tartalmazza az e-mail cím(eke)t
+* ''IV+OV – Hybrid''
+*:- Egyéni és szervezeti adatok egy tanúsítványban
+*:- Hasznos nagyvállalati környezetben
-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:
+<br>
-# 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ó.
+  Az alábbi típusok az oldalon helyben megjelölt díjazásért cserében igényelhetők, bankkártyával fizetve az igénylési folyamat végén:
-# 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ó. <span style="color: red;">Ezt a metódust javasoljuk mindenki számára, stabilan, gyorsan működik a tapasztalataink alapjá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.
-==== Metódus módosítása ====
+==== <span style="color: red;">eSignatures (elektronikus aláírások)</span> ====
-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.
+'''''Mire jó?'''''  <br>
+Ezzel a tanúsítvánnyal hiteles elektronikus aláírást lehet létrehozni – például hivatalos dokumentumok, szerződések aláírására, ugyanúgy, mintha kézzel lenne aláírva, papíron.<br>
+'''''Kinek van rá szüksége?'''''  <br>
+Magánszemélyeknek, cégek munkatársainak vagy hivatalos ügyintézőknek, akik dokumentumokat írnak alá elektronikusan.
-=== Departments (Szervezeti egységek) ===
+* ''Remote Qualified eSignature''<br>Jogilag hitelesített, eszközfüggetlen minősített aláírás. Használható:
-==== Department létrehozása: ====
+*:- Szerződések (értékesítés, munka, bérlet, biztosítás stb.)
+*:- Tranzakciók (e‑kereskedelem, online bankolás stb.)
+*:- Közigazgatási ügyintézés (adóbevallás, anyakönyvi kivonat kérése stb.)
+* ''Qualified eSignature in cryptographic device (token)''<br>Minősített aláírás USB‑tokenen vagy smartcardon
+*:- Ugyanazok a felhasználási területek, mint a Remote Qualified eSignature-nél
+* ''Advanced eSignature (legacy Class B)''<br>Haladó elektronikus aláírási tanúsítvány korábbi (Class B) szabvány szerint
+*:- Dokumentumok digitális aláírására, jogi elismeréssel
-# 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.
+==== <span style="color: red;">eSeals (elektronikus pecsétek)</span> ====
-# 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"'').
-# 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.
-==== Departmenthez tartozó adminok ====
+'''Mire jó?'''  <br>
-Most már létrehozhat olyan adminisztrátorokat, akik DRAO jogosultsággal rendelkeznek és csak ehhez az egységhez kapcsolódnak, nem pedig az egész szervezethez.
+Ez nem egy személyhez, hanem egy '''szervezethez''' kapcsolódik. Olyan, mint egy pecsét, amit automatikusan rá lehet tenni digitális dokumentumokra – például számlákra, igazolásokra.<br>
+'''Kinek van rá szüksége?'''  <br>
+Cégeknek, intézményeknek, akik automatizált módon „hitelesítenék” dokumentumaikat (pl. e-számlák, gép által generált igazolások).
-==== A Departmenthez kapcsolódó domainek ====
+* ''Remote Qualified eSeal''<br>Hagyományos pecséttel jogilag egyenértékű, eszközfüggetlen
-Ha olyan department adminisztrátorokat (DRAO) ad hozzá, akik jóváhagyhatják a részleg tanúsítványait, akkor érdemes korlátozni őket a szervezeti egység saját domainjeire (department-example.com) vagy a fő domain aldomainjére (department.example.org).
+*:- CertManager vagy API felületen keresztül, bármilyen eszközről használható
-Az első esetben, amennyiben egy teljesen új domain van a részleg számára, akkor kövesse a fenti szokásos domain validálási eljárást a department-example.com és a *.department-example.com esetében, a szervezeti egység számára delegálva azt.
+*:- Tartalmazza a szervezet hivatalos adatait
-A második esetben, amikor az aldomainhez tartozó fő domain már hitelesítve van, adja hozzá a department.example.org és  a *.departement.example.org domaint a department számára delegálva, de ekkor már nem kell kezdeményezni a DCV folyamatot, mivel az SCM elég okos ahhoz, hogy tudja, az  example.org már érvényesítve van. Amint a fő domain esetében, itt is meg kell várni a  department.example.org státuszának ''"Validated"''-re váltását, amit némi késéssel a *.department.example.org-é követ.
+*:- Havi 500 ingyenes aláírás; többlet aláírás díjköteles (support@harica.gr)
+* ''Advanced eSeal''<br>Haladó pecsét tanúsítvány jogilag kötelező dokumentumokhoz
+*:- Tartalmazza a szervezeti adatokat és aláírási logokat
-== Adminisztrátorok ==
+==== <span style="color: red;">Code Signing (kódaláírás)</span> ====
-További rendszergazdákat hozhat létre (RAO-kat az egész szervezet számára, vagy DRAO-kat a szervezeti egységek számára) az  Admins
+'''Mire jó?'''  <br>
-lapon az '''''Add''''' gombra. A meglévő adminisztrátorokat szerkesztheti is, ha kiválasztja, majd megnyomja az Edit gombot.
+Ezzel tanúsítható, hogy egy program vagy alkalmazás '''valóban attól származik, aki kiadta''', és nem módosították utólag.<br>
-# 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.
+'''Kinek van rá szüksége?'''  <br>
-# 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.
+Szoftverfejlesztőknek és cégeknek, akik alkalmazásokat, programokat készítenek és szeretnék, hogy azt biztonságosnak ismerje fel a rendszer (Windows, macOS, stb.).
-# 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!
-# Válassza ki a kívánt szerepeket a '''''Roles''''' alatt, azaz RAO-t az egész szervezet számára vagy DRAO-t a létrehozott szervezeti egység számára, valamint azon tanúsítványtípust (SSL, kliens vagy kód aláírás) amely igénylését lehetővé kívánjuk tenni a számára.
-# Ha kész, akkor a kiválasztott jelszót közölnie kell az új adminisztrátorral (a rendszer nem küld e-mailt).
-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.
+* ''IV – Individuals/Sole Proprietorships''<br>Alkalmazások, driverek, futtatható állományok digitális aláírása
-Ú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 Ügyfélszolgálat emailcímére], hogy beállítsuk azokat.
+*:- Tartalmazza a természetes személy Publisher adatait
+* ''OV – Organizations''<br>Szoftver- és kódaláírás szervezetek részére
+*:- Tartalmazza a jogi személy adatait
+* ''EV – Extended Validation''
+*:- Azonnali reputáció Microsoft Windows rendszeren
+*:- Részvétel a Windows Hardware Compatibility programban
+*:- Hivatalos cégnyilvántartási adatok feltüntetésével
-=== Zárolt felhasználói fiók ===
+==== <span style="color: red;">Email (S/MIME tanúsítványok)</span> ====
-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 Ügyfélszolgálatnál].
+* ''IV – Individuals/Sole Proprietorships''<br>Magánszemélyi tanúsítvány e-mail aláírásra/titkosításra
+*:- E-mail cím és természetes személy adatok
+* ''OV – Organizations''<br>Szervezeti e-mail tanúsítvány
+*:- E-mail cím és céginformációk
-== SSL (szerver) tanúsítványok ==
+==== <span style="color: red;">Client Authentication (ügyfél hitelesítés)</span> ====
-=== Tanúsítványok kérelmezése és jóváhagyása az SCM-ben adminisztrátorként ===
-Lépjen a '''''Certificates → SSL certificates''''' elemre, és a tanúsítvány igényléséhez nyomja meg az '''''Add''''' gombot.
+'''Mire jó?'''  <br>
-# Válassza ki a ''"Manual creation of CSR"'' opciót.
+Ez egyfajta '''digitális igazolvány''', amivel egy rendszer azonosítani tudja a felhasználót. Például belépéshez használható egy webes portálra.<br>
-# Adjon meg egy CSR-t a szövegmezőbe való beillesztéssel, vagy töltse fel fájlként az '''''Upload CSR''''' gomb segítségével.
+'''Kinek van rá szüksége?'''  <br>
-# Válassza ki és töltse ki a megfelelő információkat a ''"Basic info"'' lépésben. Győződjön meg arról, hogy egy több domaint tartalmazó tanúsítványhoz a megfelelő típust választotta, hogy egy szöveges mezőt kapjon, ahol szükség esetén megadhatja a ''"Subject Alternative Names"'' - alternatív domainneveket. Ha valaki más nevében kéri, felveheti az e-mail címét külső igénylőként.
+Egyetemek, intézmények dolgozói vagy diákjai, ha olyan belépési rendszert használnak, ami tanúsítványalapú azonosítást vár el.
-# További beállítási lehetőségekhez kattintson a ''"Click here for advanced options"'' feliratra, hogy hozzáférjen egy megjegyzés mezőhöz, ahol megadhatja azokat az információkat, amelyeket később a tanúsítványban szeretne látni. Ne távolítsa el a címmezőket a ''"Remove"'' jelölőnégyzetek használatával, mivel ez úgy tűnik, hogy a tanúsítvány elakad, mivel az információ nem egyezik az előzetesen validált szervezet adataival.
-# A következő képernyőn fogadja el vagy utasítsa el az automatikus megújítást, és fejezze be az '''''OK''''' gombbal.
-Ha az igénylő rendelkezik az ''"Allow SSL auto approve"'' jogosultsággal, akkor a tanúsítvány automatikusan jóváhagyásra kerül, és megjelenik mellette az ''"Applied"'' felirat. Ha az adminisztrátor nem rendelkezik ezzel a jogosultsággal, akkor a tanúsítvány ''"Requested"'' állapotba kerül, és manuálisan kell elfogadni a tanúsítvány kiválasztásával és az '''''Approve''''' megnyomásával.
+* ''IV (User)''<br>Felhasználói hitelesítés tanúsítvány. Tartalmazhatja:
-Amikor a tanúsítvány kiadásra kerül, annak státusza ''"Issued"'' lesz, és e-mailt kap erről az igénylő.
+*:- Természetes személy adatait
-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.
+*:- Kapcsolódó szervezet adatait
+*:- E-mail cím(eke)t
+*:- Egy vagy több domaint
+* ''OV (Machine)''<br>Gép- vagy szolgáltatáshitelesítő tanúsítvány
+*:- Tartalmazza a szervezet adatait, e-mailt és doméneket
-=== CSR generálására példák ===
+<br>
-'''Egy domain esetén'''
+'''További információ'''
-<syntaxhighlight line>
+A részletes leírások és megrendelési lehetőségek elérhetők a HARICA hivatalos weboldalán: https://www.harica.gr/certificates.
-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'''
+== Tanúsítvány igénylés ==
-<syntaxhighlight line>
+Minden tanúsítvány igénylés a rendszer bal oldali menüjében található menüpontokkal történik.
-openssl req -new -newkey rsa:4096 -nodes \
+A tanúsítványkérelmek létrehozásához rendelkeznie kell egy felhasználóval a rendszerben (lásd fent), de a felhasználónak nem kell szerepkörrel rendelkeznie.
--out domainX_kifu_hu.csr \
+Felhasználó saját kérését nem hagyhatja jóvá, még akkor sem ha adminisztrátor. Ezt egy másik Szervezeti jóváhagyó (Approver) szerepkörrel rendelkező felhasználónak kell megtennie. Ezzel szemben, ha administrátor fogja jóváhagyni a tanúsítványt, akkor egy másik felhasználónak kell igényelnie.
--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'''
+'''Figyelem Approver-eknek:''' Tanúsítványigénylést bárki be tud küldeni, akár másik intézménytől is, ezért <span style="color:red;">érdemes alaposan ellenőrizni az igénylést, beleértve az igénylő személyét is, hogy valóban jogosult a cert kiadására!</span>
-<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.
+=== Szerver tanúsítványok ===
+Használja a Certificate '''Requests → Server''' útvonalat.
-<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>
+Az első oldalon adjon meg egy opcionális becenevet a tanúsítványnak, majd adjon hozzá egy vagy több domain nevet, amely szerepelni fog a tanúsítványban. Az első hozzáadott név a tanúsítvány CN-je lesz, és az összes hozzáadott név SAN DNS-bejegyzésként jelenik meg a tanúsítványban. Ha nem törli a jelölést a név alatti jelölőnégyzetből, akkor a rendszer hozzáad egy további nevet a www előtaggal SAN DNS-ként.
-=== Nem adminisztrátor jogosultságú igénylések engedélyezése ===
+A becenév csak a kérelmező számára jelenik meg a tanúsítvány listákon. A jóváhagyók/adminisztrátorok nem fogják látni. Javasoljuk, hogy hagyja üresen, mivel ebben az esetben a CN (az első beírt domainnév) jelenik meg.
-Lehetőség van nem adminisztrátori jogkörrel rendelkező személyeknek is engedélyezni, hogy tanúsítványkérelmet nyújtsanak be az SCM
-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 [[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 ===
+CAA rekord megléte a domain zónájában nem kötelező, csak ha már létezik más CA-hoz tartozó CAA. Ez esetben megjeleníti milyen CAA-kat szeretne látni:
-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:
+<syntaxhighlight>
-[[Fájl:Sectigo EV Details.png|bélyegkép]]
+CAA 0 issue "harica.gr"
-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.
+CAA 0 issuewild "harica.gr"
+</syntaxhighlight>
-== Személyes tanúsítványok ==
+A később feltöltött CSR-ből nem veszik fel a tanúsítványhoz tartozó neveket. Ebben a szakaszban hozzá kell adnia őket. Ez a jövőben változhat.
-=== Önkiszolgáló portál SAML használatával ===
-==== Az IdP és az SCM konfigurálása a portál engedélyezéséhez ====
-Az önkiszolgáló portál a következő címen található: https://cert-manager.com/customer/KIFU/idp/clientgeant
+Jelenleg legfeljebb 100 domain név adható meg (és feltételezzük, hogy ez összesen 200-t jelent, ha elfogadja az összes www-előtt nevet is).
-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 [[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.
-Ahhoz, hogy a felhasználók használhassák az IGTF / grid tanúsítványokat, a következőkre is szükség van:
+Wildcard tanúsítvány a szokásos eljárással igényelhető. Például a domainnév mezőben a ''*.example.com'' formában adjuk meg. Ilyenkor az ''example.com''-t nem kell a kérésbe belefoglalni.
-* Szerkessze az '''''Organization''''' objektumot, és állítsa be a ''"Secondary Organization Name"'' mezőben a grid tanúsítványokban használt nevet. 	Mivel a grid tanúsítvány objektumokat "felhasználónévként" használják a rendszerekben, elengedhetetlen, hogy a teljes tárgysorozatot úgy tárolják, ahogy korábban is történt a felhasználók számára.
-* Küldjön a fentiekről az ugyfelszolgalat@kifu.hu -ra e-mailt , miszerint kéri a másodlagos név érvényesítését, mivel ezt a lépést nem tudja végrehajtani, és akkor elindítjuk ezt a folyamatot.
-==== Az érintett szerverek konfigurálása grid / IGTF használatához ====
+A következő oldalon válassza ki a tanúsítvány típusát:
-A "sima" kliens tanúsítványokhoz nem kell semmilyen beállítást elvégeznie.
+# DV – mindig elérhető, amint a domain validálása megtörtént, és csak a domain információkat tartalmazza. Ez a típusú tanúsítvány hasonlít leginkább arra tanusítványra, amelyet a Let's Encrypt-től lehet kapni.
-A grid / IGTF tanúsítványoknál győződjön meg arról, hogy a szerverek rendelkeznek-e a legfrissebb IGTF Trust Anchor Distributionnel, amely magában foglalja ezt a sort: <span style="color: red;">"/C=NL/O=GEANT Vereniging/CN=GEANT eScience Personal CA4"</span> (megtalálható a <span style="color: red;">ca_GEANTeSciencePersonalCA4-1.105-1.noarch.rpm</span> vagy újabb RPM csomagban)
+# OV – a Szervezet érvényesítése után érhető el. Ez ugyanaz a típusú tanúsítvány, amelyet korábban a Sectigo-tól lehetett kapni.
+# EV – Ne válassza a '''„Vállalkozásoknak vagy szervezeteknek (EV)”''' lehetőséget, mert ez a fajta tanusítvány NEM része a HARICA TCS ajánlatának, mivel már nem látjuk értékét ennek a tanúsítványtípusnak az alapértelmezett opcióként való támogatásában. Ezeket (EV TLS) és más típusú tanúsítványokat (kódaláírás, minősített elektronikus aláírások/bélyegzők, QWAC-ok) és távoli aláírási szolgáltatásokat egyedileg is meg lehet vásárolni a HARICA-tól, ha speciális felhasználási eseteknél szükség van rá.
-==== A portál használata ====
+Ha a DV vagy OV opció a ''“free”'' helyett ''“from AMOUNT€ year”'' felirattal jelenik meg, ne folytassa. A valószínű okok a következők:
-Az itt található utasítások a tanúsítványokat ismerő RAO-knak szólnak. Lehet, hogy ki kell bővítenie ezt, amikor utasításokat ad a végfelhasználóknak, például megmutatni nekik, hová importálják a tanúsítványokat a támogatott böngészőkben, stb.
+* Elírást vétett, és olyan domain nevet adott meg, amely nem tartozik az Ön Szervezetéhez. Kezdje elölről, és ellenőrizze, hogy a nevek helyesek-e.
-Így kaphat tanúsítványt:
+* Olyan domaint próbált használni, amelyet még nem adott hozzá és nem validált a rendszerben. (Lásd fent: További domainek hozzáadása) Erősítse meg a típusválasztást, majd erősítse meg az információkat, és fogadja el a használati feltételeket stb.
-# Nyissa meg a https://cert-manager.com/customer/KIFU/idp/clientgeant oldalt, válassza ki a szervezet IdP-jét, és jelentkezzen be oda.
-# Válassza ki a megfelelő tanúsítási profilt:
-#* ''"GÉANT Personal Certificate"'' - normál kliens tanúsítványhoz, e-mail aláírásra stb. a grid/IGTF felhasználási területen kívül.
-#* ''"GÉANT IGTF-MICS Personal"'' - grid/IGTF személyes (kliens) tanúsítványhoz normál használathoz.
-#* ''"GÉANT IGTF-MICS-Robot Personal"'' - grid/IGTF robot személyes tanúsítvány (ritkán használt).
-# Válassza ki, hogy a kulcsot a kiszolgáló oldalán vagy helyileg generálja. Noha az előbbi sokkal kényelmesebb, policy vagy technikai okokból kifolyólag kellhet esetenként az utóbbi:
-#* Használja a "Generate RSA" elemet, ha szerver-oldalon generált kulccsal szeretne tanúsítványt igényelni.
-#* 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:
-<code>openssl req -new -newkey rsa:2048 -out usercert_request.pem -keyout userkey.pem -subj '/CN=Teszt'<br />
-chmod go = userkey.pem<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.
-# Kattintson a '''''Submit''''' gombra, és fogadja el a feltételeket.
-# 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:
-<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.
-=== Kliens tanúsítványok visszavonása ===
+A Submit Request lépésben használja a CSR beküldése manuálisan lehetőséget, hogy beillessze a CSR-t. Fogadja el újra a használati feltételeket stb., és küldje el a kérelmet.
-A végfelhasználók nem tudják visszavonni a tanúsítványokat az önkiszolgáló portálon. Jelezni kell számukra, hogy az adminisztrátorokkal kell kapcsolatba lépniük ezen szándék esetén. Rao adminisztrátorok visszavonhatják a tanúsítványokat a '''''Certificates → Client certificates''''' menüben, kiválasztva a megfelelő személyt, rá kell kattintani a Certificates gombra, kiválasztani a megfelelő tanúsítványt, és a Revoke gombra kattintani.
+CSR generálás a következő paranccsal lehetséges: (4096 bites RSA kulcs létrehozásához)
+<syntaxhighlight lang="bash">
+openssl req -new -newkey rsa:4096 -nodes \ -out peldadomain.hu.csr \ -keyout peldadomain.hu.key \ -subj "/C=HU/L=Budapest/O=Pro-M Zrt/CN=peldadomain.hu"
+</syntaxhighlight>
+Azonban a -subj utáni résznek nincs jelentősége, mert:
+* DV esetén nem lesz értelme, mert csak a CN-t tartalmazza,
+* OV esetében pedig a Szervezet - annak létrehozásakor megadott - '''C=HU,L=Budapest,O=Pro-M Zrt.''' értékeit fogja felvenni.
-=== Kliens tanúsítványok kiállítása az SCM használatával ===
+Ha az “Auto-generate CSR” módot választjuk, akkor a privát kulcs közvetlenül jön létre, és a rendszer automatikusan generálja a CSR-t. Ekkor a privát kulcsot védő, legalább 8 karakteres jelszó megadása szükséges, és a privát kulcs letöltésének megtörténtét is meg kell erősíteni. Annak pótlására nincs lehetőség a későbbiekben.
-''Megjegyzés: ez egy tartalék megoldás. A személyes tanúsítványok kiadásának fő módja a fentebb tárgyalt önkiszolgáló portálon keresztül történik.''
-# RAO adminisztrátorként menjen a '''''Certificates → Client certificates''''' menübe és használja az '''''Add''''' gombot. Válassza ki a megfelelő szervezetet, szervezeti egységet és domaint. Töltse ki az e-mail címet és a nevet. Töltse ki a külön névmezőket. Hagyja üresen a ''Secret ID'' és a ''Validation Type Standard'' mezőket.
-# Most már hozzáadta a kívánt személyt. Kattintson rá, hogy bepipálja a sor elején a checkboxot, majd kattintson a '''''Certificates''''' gombra. Itt a '''''Send invitation''''' használatával kiküld egy meghívó emailt a felhasználónak, amely egy egyszeri hozzáférést biztosít a számára ügyféltanúsítvány létrehozására.
-# A felhasználónak meg kell adnia egy jelszót (amelyet a generált PKCS#12 fájl titkosításához használnak) és egy  ''Passphrase''-t (mely révén a felhasználható az Ön segítségét nélkül is vissza tudja vonni a tanúsítványt), valamint el kell fogadnia a feltételeket.
-# A felhasználó ezután kap egy PKCS#12 fájlt, amely tartalmazza a kulcsot, a tanúsítványt és a láncot, készen a webböngészőkbe való importálásra.
-''Érdemes megjegyezni:''
+<blockquote>
-Ennél a módszernél a kulcs mindig a szerver oldalán jön létre. Nincs lehetőség CSR feltöltésére az ügyféloldalon generált kulcs használatával. Ez valószínűleg a felhasználók számára nem elfogadható vagy policy (nem szabad a kulcsot a szerveroldalon generálni) vagy technikai okok (a kulcs nem exportálható hardver eszközről) miatt. Az önkiszolgáló portál használatakor van lehetőség a CSR feltöltésére.
+<span style="background-color: #f0f0f0; padding: 2px;">2025-01-16-án felfedezett BUG: A következő hibaüzenet jelenhet meg: '''”You have already used this key before. If your private key gets compromised, we will have to revoke ALL CERTIFICATES associated with this key.“''' ha van egy üres sor a CSR előtt a mezőben (és esetleg más szintaktikai hibák esetén is). Ne folytassa, hanem ellenőrizze, hogy a CSR formátuma megfelelő-e, és küldje be újra. Természetesen akkor is ezt az üzenetet fogja kapni, ha újra megpróbál egy kulcsot használni.</span>
+</blockquote>
-== Értesítések ==
+Tanúsítványkérelme mostantól a függőben lévő (Pending) tanúsítványok között lesz felsorolva, amíg az egyik Szervezetéhez tartozó jóváhagyó jóvá nem hagyja azt. A függőben lévő jóváhagyásról e-mailt küld a rendszer az intézyményi értesítési aliasra.
-A '''''Settings → Notifications''''' menüpont alatt létrehozhatja és szerkesztheti azokat az értesítéseket amiket kiküld a rendszer, ha bizonyos feltételek teljesülnek. Az '''''Add''''' gomb használatával választhat egyet a rendelkezésre álló értesítési típusokból:
-* Legalább a tanúsítványok lejáratával kapcsolatban érdemes értesítést beállítani, ehhez az '''''SSL Expiration''''' opciót kell választani. A '''''DCV Expiration'''''-t ugyanezen okból szintén javasolt beállítani.
-* Ha lehetővé tette a nem adminisztrátor felhasználók számára, hogy tanúsítványokat igényeljenek (lásd fent), akkor ajánlott az '''''SSL Awaiting Approval''''' használata, hogy figyelmeztetést kapjon a RAO arról, hogy jóvá kell hagyni egy igénylést.
-* Kérjük, ne engedélyezze a '''''"Notify MRAO Admin(s)"''''' elemet, mivel ilyenkor ez e-mailt küld a KIFÜ "superusereinek" is.
-Ha módosítania kell a rendszerből küldött e-mailek szövegét, akkor ezt megteheti a '''''Settings → Templates → Email template''''' menüpont alatt.
+Ha egy Szervezetéhez tartozó jóváhagyó jóváhagyta a tanúsítványt, a listában a tanúsítványtól jobbra található letöltési nyíl segítségével töltheti le.
-== SAML konfiguráció ==
+=== IGTF (aka Grid, eScience) Server Certificates - IGTF szerver tanúsítványok ===
-=== Állítsa be az IdP-t a Sectigo-val való együttműködéshez ===
+'''Előfeltételek'''
+# IGTF OV szerver tanúsítvány igényléséhez a szervezethez be kell kapcsolni az IGTF tanúsítványigénylés engedélyezését. Ezt a szervezet információi oldalon a jobb felső sarokban lévő ''Tags'' gombon megjelenő ablakban lehet megtenni. (Admin szintű jogosultság szükséges)
+# Megtörtént az Organization Validation eljárás.
-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.
+'''Igénylés'''
-A következő attribútumokat kell közzétenni az EntiyId-ben (https://cert-manager.com/shibboleth):
+Szervertanúsítvány igénylésekor a második oldalon (a nevek megadása után) válassza az OV típust. Erősítse meg a következő oldalon. Ezután a „Szervezeti adatok” oldalon jelölje be az „IGTF eScience digitális tanúsítvány igénylése” jelölőnégyzetet. Ahogy ott is szerepel, az „L” és „O” névkomponensek szükség szerint ASCII karakterekké alakulnak.
-* 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 ===
+=== IGTF (aka Grid, eScience) Client Auth Certificates – IGTF kliens auth tanúsítványok ===
-Miután az IdP rendszergazdái bekonfigurálták a szükséges attribútum kiadását, ellenőrizze azt a https://cert-manager.com/customer/KIFU/ssocheck oldalon. Ehhez a teszthez csak az eduPersonPrincipalName és a mail szükséges, a személyes tanúsítványokhoz viszont a giveName, sn, displayName, schacHomeOrganization és eduPersonEntitlement (amelyek jelenleg nem jelennek meg a tesztben) is szükségesek. A további vizsgálatokra és tesztelésre bejelentkezés után az alábbi oldalon van lehetőség: https://cert-manager.com/Shibboleth.sso/Session
+'''Előfeltételek'''
-Itt megtudhatja, mely attribútumokat kapja meg a Sectigo az Ön IdP-jétől.
+* Be kell kapcsolni az IGTF tanúsítványigénylés engedélyezését. Ezt a szervezet információi oldalon a jobb felső sarokban lévő Tags gombon megjelenő ablakban lehet megtenni. (admin role szükséges)
+* Konfigurálja az IdP-t, hogy a szükséges attribútumokat kiadja a HARICA-nak. Lásd az alábbi „SAML konfiguráció” részt. :?:
-=== Konfigurálja az SCM-et ===
+'''Igénylés'''
+# Jelentkezzen be a https://cm.harica.gr/ címen az Academic Login és az IdP-nél használt felhasználónevével. Ehhez a működéshez Academic Login szükséges.
+# A bal szélen található menüben válassza az IGTF klienshitelesítés lehetőséget. Ne válassza a Klienshitelesítés lehetőséget (ami a szerződésünkben nem szereplő, nem IGTF hitelesítési tanúsítványokhoz tartozik).
+# Válassza a GÉANT személyes hitelesítést tanúsítványtípusként, és erősítse meg ezt újra a következő oldalon.
+# Fogadja el a feltételeket, és folytassa a Kérés elküldése gombbal.
+# Használja a Tanúsítvány regisztrálása gombot a Kész tanúsítványok listában.
+# Használja a Tanúsítvány generálása lehetőséget a következő oldalon, és győződjön meg arról, hogy olyan jelszót választ, amelyre később emlékezni fog. Jelölje be a „Megértettem…” jelölőnégyzetet, és folytassa a Tanúsítvány regisztrálása gombbal.
+# Használja a Letöltés gombot a Tanúsítvány beszerzése oldalon a kulcsot és a tanúsítványt tartalmazó PKCS#12 fájl mentéséhez.
+# Importálja a PKCS#12 fájlt oda, ahol szüksége van rá.
-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:
+* A kiemelt felhasználók dönthetnek úgy is, hogy manuálisan küldik el a CSR-t (miután korábban generáltak egy kulcsot, és szükség szerint kombinálják a kulcsot és a letöltött tanúsítványt).
-* 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 ==
+=== ACME / Certbot használata ===
-A Sectigo REST API dokumentáció megtalálható a https://support.sectigo.com/Com_KnowledgeProductPage?c=Sectigo_Certificate_Manager_SCM
+Ez a funkció jelenleg még általunk is tesztelés alatt áll, utána feltöltjük magyar nyelvű leírással ezt a részt is. Addig is angol nyelven az alábbi leírások érhetőek el:
-az "SCM - Sectigo Certificate Manager REST API" dokumentumban.
-Javasoljuk, hogy hozzon létre külön RAO vagy DRAO adminisztrátorokat az API-val történő műveletekhez, ne azokat a adminisztrátorokat használja, akiket a webes felhasználói felületen végzett tevékenységekhez. Csak API-hoz használni kívánt adminisztrátor létrehozása:
-# Használja a RAO adminisztrátort az új admin létrehozásához, ugyanúgy, mint egy "normál webfelület adminisztrátort", beleértve az ideiglenes jelszó beállítását. Nem fogja tudni használni az API-t ezzel az ideiglenes jelszóval.
-# Jelentkezzen be az új adminisztrátor felhasználóval az SCM felületén, és hajtsa végre a kötelező kezdeti jelszó megváltoztatását.
-# 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 ===
+* [https://wiki.geant.org/pages/viewpage.action?spaceKey=TCSNT&title=TCS+2025+FAQ#TCS2025FAQ-HowdoIuseACME? HARICA ACME funkció használata (EduID belépés)]
+* [https://guides.harica.gr/docs/Guides/Server-Certificate/ACME-Instructions/ HARICA saját leírása az ACME beállításáról]
-A certbot egyelőre béta verziójú, ennek figyelembevételével használja mindenki!
+== Értesítések e-mailben ==
+=== Értesítések lejáró S/MIME tanúsítványok esetében ===
+''Terv alatt álló funkció:''
-# 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.
+Egyedi tanúsítványigénylések esetén a rendszer automatikusan lejárati értesítést küld a CertManager portálról, a tanúsítványban szereplő e-mail címre, a lejárat előtt 30, 15, 5 és 1 nappal.
-[[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 ==
+Tömeges (bulk) igénylések esetén a felhasználók egyetlen értesítést kapnak 30 nappal a lejárat előtt, közvetlenül a tanúsítványkiadótól (CA).
-=== 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]
+A tanúsítvány lejáratáról szóló e-mail az alábbihoz hasonló:
-=== Sectigo támogatás ===
+<blockquote style="background-color: #f9f9f9; border-left: 3px solid #ccc; padding: 0.5em;">
+A xxxxxxxxxxxx sorszámú tanúsítvány, amely az alábbi entitás részére került kiadásra:<br/>
+E=xxxxx@auth.gr, CN=Aristotle University of Thessaloniki, O=Aristotle University of Thessaloniki, L=Thessaloniki, C=GR,<br/>
+és amelyet az alábbi tanúsítványkiadó bocsátott ki:<br/>
+CN=HARICA S/MIME RSA SubCA R3, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR,<br/>
+lejár: 2025-05-14 10:14:45+03:00.
+</blockquote>
-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."''
+Amint a tömeges kérésekkel kiadott S/MIME tanúsítványok is megjelennek a "S/MIME Certificates" fülön, az értesítési rendszer ezekre is alkalmazni fogja a fenti figyelmeztetési időpontokat.
-=== Sectigo dokumentáció ===
+=== Szervezeti események ===
+Az Organization felvételekor megadott emailcím értesítést kap:
+* tanúsítvány igénylés érkezése
+* tanúsítványigénylés elfogadása
+* tanúsítvány visszavonása
+* domain validálása
-A Sectigo teljes dokumentációja megtalálható az [https://support.sectigo.com/Com_KnowledgeProductPage?c=Admin_Guides&k=&lang= alábbi webhelyen].
+== Leírások angol nyelven ==
-Néhány javaslat:
+* [https://wiki.geant.org/download/attachments/926744633/Enterprise%20Admin%20Guide.pdf Enterprise Admin Guide]
-* ''"SCM - Sectigo® Certificate Manager Quick Start Guide"'' - az SCM rendszer rövid bemutatása
+* [https://wiki.geant.org/download/attachments/926744633/Enterprise%20Approver%20Guide.pdf Enterprise Approver Guide]
-* ''"SCM - Sectigo Certificate Manager Administrator’s Guide"'' - lényegesen hosszabb, és alaposabb leírás a szolgáltatásról
+* [https://guides.harica.gr Hivatalos útmutatók]
-* ''"SCM - Sectigo Certificate Manager REST API"'' - a REST API leírása, automatizálási lehetőségek
-=== GÉANT Trusted Certificate Service (TCS) ===
+== Segítség ==
+=== PRO-M ügyfélszolgálat ===
-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
+Amennyiben ez a dokumentum nem tartalmazza a kérdésre a választ vagy megoldást a problémájára, az alábbi oldalon keresztül jelezhet nekünk: [https://www.pro-m.hu/ugyfelszolgalat PRO-M Ügyfélszolgálat]
-<br />TCS repository: https://wiki.geant.org/display/TCSNT/TCS+Repository