Gerege eID — Үндэсний CA-д онбординг (L1 CSR → гинж)¶
Хуулиар Gerege нь үндэсний root CA-тай заавал chain хийнэ — subordinate (дэд) CA, бие даасан root биш. Эцсийн шатлал:
Үндэсний Root CA (Засгийн газрын HSM) └── Gerege CA (L1) — үндэсний root ГАНЦ үүнийг гарын үсэглэнэ; pathlen:1 ├── Gerege Personal Issuing CA (L2, pathlen:0) → хувь хүний (Natural Person) cert └── Gerege Organization Issuing CA (L2, pathlen:0) → байгууллагын (Legal Person) certeIDAS нэршил: Personal = Natural Person, Organization = Legal Person. L1-ийн дор хоёр тусдаа L2 Issuing CA (зорилго/бодлогоор салгасан) — бодит HSM-ээр баталгаажсан (
TestHSMProxyDualIssuingCA).
1. L1 CSR — агуулга (бодит HSM-ээр баталгаажсан)¶
internal/crypto доторх TestPrepareL1CSR нь L1 CSR-ийг HSM түлхүүрээр (PoP) гаргана:
Subject: C=MN, O=Gerege Systems LLC, CN=Gerege eID CA
Public-Key: RSA-2048 (ceremony 7-р сар 2048; 4096 ~1 жил дараа)
Requested Extensions:
Basic Constraints: critical, CA:TRUE, pathlen:1 ← 2-давхар (L1→L2)-д ЗААВАЛ
Key Usage: critical, Certificate Sign, CRL Sign
Signature: sha256WithRSAEncryption (proof-of-possession verify OK)
Subject DN-ийг үндэсний CA-гийн нэрлэх журамд тааруулна (тэд тодорхой O/CN/ organizationIdentifier шаардаж магадгүй). Дээрх нь зөвлөмж.
2. (!) Үндэсний CA-аас БИЧГЭЭР авах зүйл¶
| Зүйл | Яагаад |
|---|---|
| pathLenConstraint ≥ 1 | Эцсийн L1 cert-ийн pathlen-ийг үндэсний root шийднэ (CSR зөвхөн хүснэ). 0 бол Gerege L2 гаргаж чадахгүй → 2-давхар БҮТэхгүй. Subordinate CA гэрээнд тусгуул. |
| Algorithm / key size | RSA-2048 (одоо) — тэдний ceremony/CP-CPS-тэй нийцэх |
| Validity | L1 нь root-оос богино |
| DN / нэрлэх журам | O/CN/organizationIdentifier |
| CRL/OCSP журам | AIA/CDP URL хаашаа заах |
3. Бодит CSR-ийг ХЭЗЭЭ үүсгэх¶
Бодит L1 түлхүүр нь албан ёсны key ceremony (7-р сар, RSA-2048)-д M-of-N custodian,
tamper bag, witness-тэйгээр үүснэ — hsm-thales-gerege/docs/eid-issuing-ca-key-ceremony-script.md.
Демо түлхүүрийг ашиглахгүй. Ceremony үед CSR-ийг 2 аргын аль нэгээр:
А. Go (hsm-proxy, энэ repo): ceremony-ийн key label-ийг өгөөд
HSMPROXY_E2E_URL=https://<proxy>:8443 HSMPROXY_E2E_CERT=admin.crt HSMPROXY_E2E_KEY=admin.key \
CSR_OUT=gerege-l1.csr go test ./internal/crypto -run TestPrepareL1CSR -v
# (label-ийг ceremony key-д тааруулж тестийг өөрчилнө; демо нь түлхүүр устгадгийг АНХААР)
Б. Luna native (cmu, ceremony script-тэй нийцтэй):
cmu requestcertificate -slot <issuing> -lco \
-publichandle <ph> -privatehandle <prh> \
-sha256withrsa -outputfile gerege-l1.csr \
-cn "Gerege eID CA" -o "Gerege Systems LLC" -c MN
cmuCSR-д extension оруулдаггүй — pathlen/keyUsage-ийг гэрээгээр үндэсний root тавина.
4. L1 cert ирсний дараа¶
- Үндэсний root-оор гарын үсэглэгдсэн L1 cert-ийг Gerege HSM-д import (cert нийтийн, аюулгүй).
- Gerege дотроо хоёр тусдаа L2 issuing CA үүсгэх (тус бүр L1-ээр гарын үсэглэгдэнэ):
- Personal (Natural Person) — key label ж:
gerege-personal-issuing-ca - Organization (Legal Person) — key label ж:
gerege-org-issuing-caТус бүрpathlen:0. Байгууллагын leaf-дorganizationIdentifier(OID 2.5.4.97, ж: NTRMN-<регистр>). - Go server тохиргоо (нэг сервер хоёр issuing CA-г зэрэг ачаална):
SMARTID_PKI_CA_PROVIDER=hsmproxy- Personal:
SMARTID_HSMPROXY_KEY_LABEL=<Personal L2 key>,SMARTID_HSMPROXY_ISSUING_CERT=<Personal L2 cert> - Organization (заавал биш):
SMARTID_HSMPROXY_ORG_KEY_LABEL=<Org L2 key>,SMARTID_HSMPROXY_ORG_ISSUING_CERT=<Org L2 cert> - Сонголт автомат: ETSI угтвараар —
PNOMN-…→ Personal CA,NTRMN-…→ Organization CA (domain.SubjectTypeForEtsi+store.caFor). Org тохируулаагүй бол Personal-руу fallback. - leaf-д бүтэн гинж (L2+L1) хавсаргана; trust anchor = үндэсний root.
Бодит HSM дээр баталгаажсан: -
TestHSMProxy3LayerChain— National Root → L1 (pathlen:1) → L2 (pathlen:0) → leaf. -TestHSMProxyDualIssuingCA— L1 → {Personal, Organization} issuing CA → хоёр leaf, хоёр гинж verify OK.
Cloud HSM failover (on-prem Luna унасан үед автомат шилжилт)¶
On-prem Luna-ийн session тасарч (slot ... not found / CKR_SESSION_HANDLE_INVALID) enrollment/seal
зогсохоос сэргийлж, fallback hsm-proxy (Thales DPoD Luna Cloud HSM-ийн ард) тохируулж болно.
Ижил CA түлхүүрийг (label ижил) DPoD партишн руу backup/restore-оор cloning хийсэн байх ёстой
(партишн config prodpart1-тэй ижил — hsm-thales-gerege/docs/ceremony-rehearsal-results.md).
SMARTID_HSMPROXY_FALLBACK_URL=https://<dpod-proxy>:8443 # Cloud HSM-backed hsm-proxy
SMARTID_HSMPROXY_FALLBACK_CLIENT_CERT=/app/hsmproxy/dpod-client.crt # хоосон бол primary-ийнх
SMARTID_HSMPROXY_FALLBACK_CLIENT_KEY=/app/hsmproxy/dpod-client.key
SMARTID_HSMPROXY_FALLBACK_SERVER_CA=/app/hsmproxy/dpod-proxy-ca.crt
SMARTID_HSMPROXY_PREFER=primary # "fallback" бол Cloud-ийг ЭХЭНД (on-prem-ийг failover болгож гараар сонгох)
- Зан төлөв: primary холбогдохгүй эсвэл 5xx (slot/session) → автоматаар fallback руу; 4xx (буруу label) → failover хийхгүй. Гарын үсгийг issuing CA cert-ийн pubkey-ээр verify (буруу түлхүүртэй fallback → fail-closed). Personal + Organization issuing CA ба e-Seal client бүгдэд үйлчилнэ.
- Гараар шилжүүлэх:
SMARTID_HSMPROXY_PREFER=fallback(restart) — Cloud-ийг primary болгоно. - Тестүүд:
TestHSMProxyFailover_*(IssuingCA/PreferFallback/BothDown/4xxNoFailover/SealClientEC).
Organization issuing CA-г production-д идэвхжүүлэх (үндэсний root-ГҮЙ шатанд)¶
Одоогийн production Personal CA (eidmongol-issuing-ca-v1) нь self-signed (үндэсний L1 хараахан
байхгүй). Organization CA-г мөн ижил загвараар — HSM-д шинэ түлхүүр + self-signed cert:
- HSM хост дээр (ceremony — hsm-thales-gerege/docs/eid-issuing-ca-key-ceremony-script.md): (public/private label ИЖИЛ — hsm-proxy label-аар хайдаг; Personal түлхүүрийн конвенцтэй тааруул.)
- App хостоос cert-ийг алсаас mint хийнэ (HSM хостод дахин очих шаардлагагүй) —
cmd/hsmca-selfsignнь proxy-ийн/pubkey+/sign-digest-ээр self-signed CA cert үүсгэнэ: - .env (app хост):
SMARTID_HSMPROXY_ORG_KEY_LABEL=eidmongol-org-issuing-ca-v1,SMARTID_HSMPROXY_ORG_ISSUING_CERT=/app/hsmproxy/org-issuing-ca.crt→docker compose up -d app. - Шалгалт: startup лог "HSM-proxy Organization CA идэвхжсэн",
GET /crl/org200, admin-аас seal cert гаргахад issuer нь Organization CA байна.
Дараа нь үндэсний root бэлэн болоход хоёр CA хоёулаа L1-ээр дахин гарын үсэглэгдэнэ (дээрх §2).
e-Seal-ийг QSCD болгох (seal leaf түлхүүр HSM-д)¶
Default-оор e-Seal-ийн leaf түлхүүр серверт (software HSM, DB AES-GCM) үүсдэг тул түвшин нь
QUALIFIED. Жинхэнэ QSCD (QcSSCD + QCP-l-qscd policy) болгохын тулд seal түлхүүр бүрийг
HSM дотор байлгаж, хувийн түлхүүр серверт хэзээ ч ирүүлэхгүй байх ёстой. Загвар нь issuing
CA-тай ижил: HSM дээр ceremony-гоор key үүсгэж, сервер зөвхөн /pubkey + /sign-digest-ээр ажиллана.
Загварчлал: e-Seal нь SK-ийн адил гэрээт (managed) үйлчилгээ — байгууллага бүрд оператор тусдаа HSM key ceremony хийнэ (байгууллага өөрөө seal key үүсгэдэггүй).
- HSM хост дээр (org бүрд, EC P-256): label =
<prefix><бүртгэлийн код>(default prefixeseal-; ж. бүртгэл 1234567 →eseal-1234567):(public/private label ИЖИЛ; hsm-proxy label-аар хайдаг. Prefix-ийгcmu generatekeypair -slot <issuing> -lco \ -keytype ec -curve prime256v1 \ -labelpublic "eseal-1234567" -labelprivate "eseal-1234567" \ -sign 1 -verify 1 -encrypt 0 -decrypt 0 -wrap 0 -unwrap 0 -derive 0SMARTID_SEAL_KEY_PREFIX-ээр солино.) - .env (app хост):
SMARTID_SEAL_QSCD=true(hsmproxy CA provider + HSMPROXY creds аль хэдийн байх ёстой — эс бөгөөс сервер fail-fast зогсоно, худал QSCD зарлахаас сэргийлнэ). Prefix өөр болSMARTID_SEAL_KEY_PREFIX=eseal-. - Seal cert гаргах (admin эсвэл RP): сервер тухайн org-ийн
eseal-<код>label-ийн pubkey-г/pubkey-ээс авч Organization CA-аар cert гаргана. Хувийн түлхүүр HSM-д хэвээр. - Тамгалалт:
POST /v3/seal/{orgEtsi}— сервер digest-ийг/sign-digest-ээр (HSM key) гарын үсэглэж, cert-ийн pubkey-ээр баталгаажуулан буцаана. - Шалгалт: seal cert-ийн
certificateLevel=QSCD; admin "Байгууллагын CA" дэлгэц дээр "QSCD (QcSSCD + QCP-l-qscd)";openssl x509-д QcSSCD statement + policy 0.4.0.194112.1.3.
Ceremony хийгээгүй org-д seal cert гаргах гэвэл сервер /pubkey 404 авч алдаа буцаана
(fail-closed) — QSCD зарлагдсан атлаа software түлхүүр руу чимээгүй унахгүй.