Aller au contenu

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) cert

eIDAS нэршил: 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

cmu CSR-д extension оруулдаггүй — pathlen/keyUsage-ийг гэрээгээр үндэсний root тавина.

4. L1 cert ирсний дараа

  1. Үндэсний root-оор гарын үсэглэгдсэн L1 cert-ийг Gerege HSM-д import (cert нийтийн, аюулгүй).
  2. Gerege дотроо хоёр тусдаа L2 issuing CA үүсгэх (тус бүр L1-ээр гарын үсэглэгдэнэ):
  3. Personal (Natural Person) — key label ж: gerege-personal-issuing-ca
  4. Organization (Legal Person) — key label ж: gerege-org-issuing-ca Тус бүр pathlen:0. Байгууллагын leaf-д organizationIdentifier (OID 2.5.4.97, ж: NTRMN-<регистр>).
  5. Go server тохиргоо (нэг сервер хоёр issuing CA-г зэрэг ачаална):
  6. SMARTID_PKI_CA_PROVIDER=hsmproxy
  7. Personal: SMARTID_HSMPROXY_KEY_LABEL=<Personal L2 key>, SMARTID_HSMPROXY_ISSUING_CERT=<Personal L2 cert>
  8. Organization (заавал биш): SMARTID_HSMPROXY_ORG_KEY_LABEL=<Org L2 key>, SMARTID_HSMPROXY_ORG_ISSUING_CERT=<Org L2 cert>
  9. Сонголт автомат: ETSI угтвараар — PNOMN-… → Personal CA, NTRMN-… → Organization CA (domain.SubjectTypeForEtsi + store.caFor). Org тохируулаагүй бол Personal-руу fallback.
  10. 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:

  1. HSM хост дээр (ceremony — hsm-thales-gerege/docs/eid-issuing-ca-key-ceremony-script.md):
    cmu generatekeypair -slot <issuing> -lco \
        -keytype rsa -modulusbits 4096 -publicexponent 65537 -mech prime \
        -labelpublic "eidmongol-org-issuing-ca-v1" -labelprivate "eidmongol-org-issuing-ca-v1" \
        -sign 1 -verify 1 -encrypt 0 -decrypt 0 -wrap 0 -unwrap 0 -derive 0
    
    (public/private label ИЖИЛ — hsm-proxy label-аар хайдаг; Personal түлхүүрийн конвенцтэй тааруул.)
  2. App хостоос cert-ийг алсаас mint хийнэ (HSM хостод дахин очих шаардлагагүй) — cmd/hsmca-selfsign нь proxy-ийн /pubkey + /sign-digest-ээр self-signed CA cert үүсгэнэ:
    hsmca-selfsign -url https://hsm-proxy:8443 -label eidmongol-org-issuing-ca-v1 \
      -client-cert client.crt -client-key client.key -server-ca proxy-ca.crt \
      -subject "CN=eID Mongolia Organization Issuing CA, O=Gerege, C=MN" \
      -years 20 -out org-issuing-ca.crt        # deploy/secrets/hsmproxy/-д
    
  3. .env (app хост): SMARTID_HSMPROXY_ORG_KEY_LABEL=eidmongol-org-issuing-ca-v1, SMARTID_HSMPROXY_ORG_ISSUING_CERT=/app/hsmproxy/org-issuing-ca.crtdocker compose up -d app.
  4. Шалгалт: startup лог "HSM-proxy Organization CA идэвхжсэн", GET /crl/org 200, 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 үүсгэдэггүй).

  1. HSM хост дээр (org бүрд, EC P-256): label = <prefix><бүртгэлийн код> (default prefix eseal-; ж. бүртгэл 1234567 → eseal-1234567):
    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 0
    
    (public/private label ИЖИЛ; hsm-proxy label-аар хайдаг. Prefix-ийг SMARTID_SEAL_KEY_PREFIX-ээр солино.)
  2. .env (app хост): SMARTID_SEAL_QSCD=true (hsmproxy CA provider + HSMPROXY creds аль хэдийн байх ёстой — эс бөгөөс сервер fail-fast зогсоно, худал QSCD зарлахаас сэргийлнэ). Prefix өөр бол SMARTID_SEAL_KEY_PREFIX=eseal-.
  3. Seal cert гаргах (admin эсвэл RP): сервер тухайн org-ийн eseal-<код> label-ийн pubkey-г /pubkey-ээс авч Organization CA-аар cert гаргана. Хувийн түлхүүр HSM-д хэвээр.
  4. Тамгалалт: POST /v3/seal/{orgEtsi} — сервер digest-ийг /sign-digest-ээр (HSM key) гарын үсэглэж, cert-ийн pubkey-ээр баталгаажуулан буцаана.
  5. Шалгалт: 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 түлхүүр руу чимээгүй унахгүй.