Section 09PKIFactorArchitectDevOps
PKI integrations
Native connectors to on-premise and cloud CAs.
Last updated 2026-04-18
PKIFactor adresse les CA backend via des connecteurs typés sélectionnés par factory pattern. Aucune CA n'est cachée ni cloisonnée : vous conservez la pleine maîtrise de votre racine de confiance et pouvez en changer à tout moment.
Pas de lock-in
Chaque connecteur expose les mêmes primitives sign, revoke, renew. Vous pouvez migrer d'un backend à l'autre sans toucher au code de vos applications clientes.
9.1. Connecteurs supportés
| Backend | Mode d'intégration | Cas d'usage typique |
|---|---|---|
| ZetaCA (post-quantum) | API REST native + HSM Utimaco | Souveraineté, post-quantum, pilotage sectoriel |
| HashiCorp Vault PKI | API HTTP + AppRole / Kubernetes auth | Cloud-native, DevOps |
| Microsoft ADCS | WinRM HTTPS + CSR signing | Existant Windows, AD-intégré |
| EJBCA Community / Enterprise | API REST EST/CMP/RA | Telco, industriel |
| DigiCert ONE | API REST CertCentral | Certificats publics OV/EV |
| Sectigo (ex-Comodo) | API SCM | Certificats publics OV/EV |
| GlobalSign Atlas | API REST | Certificats publics, Document Signing |
| Let's Encrypt | ACME upstream | TLS public gratuit |
| Step-CA | Generic REST preset | DevOps, internal CA |
| Keyfactor Command | Generic REST preset | Migration, coexistence |
9.2. Exemple — Connexion HashiCorp Vault PKI
bash
curl -X POST https://pki.exemple.com/api/v1/inventory/pkis \
-H "Authorization: Bearer $TOKEN" \
-d '{
"name": "Vault PKI Production",
"type": "vault",
"base_url": "https://vault.exemple.com:8200",
"auth_method": "approle",
"auth_config": {
"role_id": "9566ebc2-...",
"secret_id": "f8c3d9e1-...",
"namespace": "acme/pki"
},
"mount_path": "pki-int/",
"default_role": "srv-tls",
"tls": { "verify": true, "ca_bundle": "-----BEGIN CERTIFICATE-----\n..." }
}'
9.3. Exemple — Connexion Microsoft ADCS (WinRM)
bash
curl -X POST https://pki.exemple.com/api/v1/inventory/pkis \
-H "Authorization: Bearer $TOKEN" \
-d '{
"name": "ADCS Corporate Issuing CA",
"type": "adcs",
"host": "adcs01.acme.local",
"port": 5986,
"use_ssl": true,
"auth": {
"method": "kerberos",
"username": "svc-pkifactor@ACME.LOCAL",
"password": "${ADCS_PASSWORD}"
},
"ca_name": "Acme Corporate Issuing CA",
"default_template": "WebServer"
}'
9.4. Exemple — Connexion ZetaCA
bash
curl -X POST https://pki.exemple.com/api/v1/inventory/pkis \
-H "Authorization: Bearer $TOKEN" \
-d '{
"name": "ZetaCA Demo",
"type": "zetaca",
"base_url": "https://zetaca.exemple.com:9443",
"auth_method": "mtls",
"auth_config": {
"client_cert_pem": "-----BEGIN CERTIFICATE-----\n...",
"client_key_pem": "-----BEGIN PRIVATE KEY-----\n..."
},
"default_profile": "pq-server-mldsa87"
}'
9.5. Sélection dynamique de la CA par template
Chaque template CLM est lié à un pki_id. Le factory pattern route la requête d'émission vers le bon connecteur sans intervention dans le code applicatif :
python
# Pseudo-code (interne PKIFactor)
def issue_certificate(template, csr):
pki = PKIRegistry.get(template.pki_id)
connector = ConnectorFactory.create(pki.type) # vault | adcs | ejbca | zetaca | ...
return connector.sign(csr, template.pki_role, template.validity_days)
9.6. Routage multi-CA
CSR + template
Template router
pki_id = 1
Vault PKI
(web-tls)
pki_id = 2
ADCS
(corp-vpn)
pki_id = 3
ZetaCA
(pq-server)