pki-design

Name: pki-design
Author: vinayaklatthe

161stars34forks

How to install pki-design?

vinayaklatthe/microsoft-security-skills/pki-design

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill pki-design

Installs into the current project.

Summary

Guidance for designing public key infrastructure (PKI) and certificate management on Azure and hybrid environments. Covers CA strategy (offline root + issuing CAs, AD CS vs managed/third-party vs public CA), Azure Key Vault certificates, HSM key protection, Entra certificate-base

Files · 1

View on GitHub

SKILL.md

1	# PKI Design
2
3	Public Key Infrastructure (PKI) issues and manages the digital certificates that underpin
4	authentication, encryption, and signing. In Azure-centric and hybrid environments this means
5	combining a trusted CA hierarchy, Key Vault storage, automated lifecycle, and certificate-based
6	authentication.
7
8	## When to use
9	Designing certificate issuance, distribution, and lifecycle for: Entra phishing-resistant CBA,
10	TLS / mTLS for services, device identity (Wi-Fi 802.1x, VPN), code signing, and S/MIME. Use
11	this skill when the question is "where do certificates come from and how do they renew", not
12	"how do I store one secret".
13
14	Do not use this skill for Key Vault secrets/keys (`azure-key-vault`) or Entra ID model
15	(`entra-id`).
16
17	## Pick the CA strategy by use case
18
19	\| If the use case is... \| CA choice \| Notes \|
20	\|---\|---\|---\|
21	\| Internet-facing TLS (websites, APIs) \| Public CA (DigiCert, GlobalSign, Let's Encrypt) \| Always; private CAs aren't trusted by browsers \|
22	\| Internal app TLS, mTLS, service-to-service \| Internal issuing CA (AD CS or managed) \| Private CA chain trusted internally \|
23	\| Entra certificate-based authentication \| Internal CA published to Entra trust store \| Pair with strong binding policy \|
24	\| Device identity (Wi-Fi 802.1x, VPN) \| AD CS or third-party PKI + Intune SCEP/PKCS \| Auto-enrollment essential \|
25	\| Code signing \| EV code signing cert from a public CA \| Hardware token; protect aggressively \|
26	\| S/MIME email signing/encryption \| Third-party public CA (DigiCert, Sectigo) \| Internal CAs not trusted by external recipients \|
27	\| Short-lived workload certs (Kubernetes) \| cert-manager with ACME or internal issuer \| Minutes-to-hours TTL \|
28
29	> Rule of thumb: never use a private CA for internet-facing services and never use a
30	> public CA for internal certificates at scale (cost + agility). Two distinct chains.
31
32	## Approach
33
34	1. Design the CA hierarchy — Offline root CA + one or more online issuing CAs.
35	Root signs issuing CA certs (long validity, e.g. 10-20 years), issuing CAs sign end-entity
36	certs (1-2 year validity).
37	*Verify: root CA host is powered off or air-gapped except for CRL signing and issuing CA
38	renewal.*
39
40	2. Protect the keys with HSM — Root CA private key in an HSM (FIPS 140-2 Level 2+).
41	Azure Managed HSM for cloud-native; on-prem HSM for AD CS. Never an unprotected
42	filesystem.
43	*Verify: `certutil -getreg ca\CSP\Provider` shows the HSM provider, not "Microsoft Software
44	Key Storage Provider".*
45
46	3. Storage and lifecycle in Key Vault — Use Azure Key Vault certificates for all
47	service certificates. Integrate with supported issuer CAs (DigiCert, GlobalSign, internal
48	via Key Vault Acmebot or partner connector) for automatic renewal.
49	*Verify: cert objects have `lifetime_actions` configured for auto-renewal at 75% of
50	lifetime; manual touch required only for new issuance.*
51
52	4. Auto-enrollment for device and user certs — AD CS auto-enrollment via GPO for domain
53	members; Intune SCEP or PKCS connector for cloud-managed devices. Never email a
54	PFX file.
55	*Verify: Intune cert profile reports > 95% deployment success; user/device cert visible in
56	personal store.*
57
58	5. Plan revocation — CRL (Certificate Revocation List) published to HTTP endpoint;
59	OCSP responder for real-time. Both must be highly available - if CRL is unreachable,
60	modern clients fail closed for high-assurance certs. Use a CDN for the CRL HTTP endpoint.
61	*Verify: CRL endpoint reachable from public internet (if external certs) and from all
62	internal clients; OCSP responder uptime > 99.9%.*
63
64	6. Monitor expiry — Key Vault sends events for upcoming expiry. Stream to a dashboard.
65	For AD CS, use a script (`certutil -view`) on a schedule. Track 90/60/30/7 days out.
66	Verify: no cert in production expires unmonitored; alerts fire 60 days before expiry.
67
68	7. Rotation discipline — Plan rotation before issuance, not when expiry approaches.
69	Service teams own renewal automation; PKI team owns CA +

People who liked this also viewed

6 picks

Type

pki-design

161stars34forks

View on GitHub

How to install pki-design?

vinayaklatthe/microsoft-security-skills/pki-design

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill pki-design

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# PKI Design
2
3	Public Key Infrastructure (PKI) issues and manages the digital certificates that underpin
4	authentication, encryption, and signing. In Azure-centric and hybrid environments this means
5	combining a trusted CA hierarchy, Key Vault storage, automated lifecycle, and certificate-based
6	authentication.
7
8	## When to use
9	Designing certificate issuance, distribution, and lifecycle for: Entra phishing-resistant CBA,
10	TLS / mTLS for services, device identity (Wi-Fi 802.1x, VPN), code signing, and S/MIME. Use
11	this skill when the question is "where do certificates come from and how do they renew", not
12	"how do I store one secret".
13
14	Do not use this skill for Key Vault secrets/keys (`azure-key-vault`) or Entra ID model
15	(`entra-id`).
16
17	## Pick the CA strategy by use case
18
19	\| If the use case is... \| CA choice \| Notes \|
20	\|---\|---\|---\|
21	\| Internet-facing TLS (websites, APIs) \| Public CA (DigiCert, GlobalSign, Let's Encrypt) \| Always; private CAs aren't trusted by browsers \|
22	\| Internal app TLS, mTLS, service-to-service \| Internal issuing CA (AD CS or managed) \| Private CA chain trusted internally \|
23	\| Entra certificate-based authentication \| Internal CA published to Entra trust store \| Pair with strong binding policy \|
24	\| Device identity (Wi-Fi 802.1x, VPN) \| AD CS or third-party PKI + Intune SCEP/PKCS \| Auto-enrollment essential \|
25	\| Code signing \| EV code signing cert from a public CA \| Hardware token; protect aggressively \|
26	\| S/MIME email signing/encryption \| Third-party public CA (DigiCert, Sectigo) \| Internal CAs not trusted by external recipients \|
27	\| Short-lived workload certs (Kubernetes) \| cert-manager with ACME or internal issuer \| Minutes-to-hours TTL \|
28
29	> Rule of thumb: never use a private CA for internet-facing services and never use a
30	> public CA for internal certificates at scale (cost + agility). Two distinct chains.
31
32	## Approach
33
34	1. Design the CA hierarchy — Offline root CA + one or more online issuing CAs.
35	Root signs issuing CA certs (long validity, e.g. 10-20 years), issuing CAs sign end-entity
36	certs (1-2 year validity).
37	*Verify: root CA host is powered off or air-gapped except for CRL signing and issuing CA
38	renewal.*
39
40	2. Protect the keys with HSM — Root CA private key in an HSM (FIPS 140-2 Level 2+).
41	Azure Managed HSM for cloud-native; on-prem HSM for AD CS. Never an unprotected
42	filesystem.
43	*Verify: `certutil -getreg ca\CSP\Provider` shows the HSM provider, not "Microsoft Software
44	Key Storage Provider".*
45
46	3. Storage and lifecycle in Key Vault — Use Azure Key Vault certificates for all
47	service certificates. Integrate with supported issuer CAs (DigiCert, GlobalSign, internal
48	via Key Vault Acmebot or partner connector) for automatic renewal.
49	*Verify: cert objects have `lifetime_actions` configured for auto-renewal at 75% of
50	lifetime; manual touch required only for new issuance.*
51
52	4. Auto-enrollment for device and user certs — AD CS auto-enrollment via GPO for domain
53	members; Intune SCEP or PKCS connector for cloud-managed devices. Never email a
54	PFX file.
55	*Verify: Intune cert profile reports > 95% deployment success; user/device cert visible in
56	personal store.*
57
58	5. Plan revocation — CRL (Certificate Revocation List) published to HTTP endpoint;
59	OCSP responder for real-time. Both must be highly available - if CRL is unreachable,
60	modern clients fail closed for high-assurance certs. Use a CDN for the CRL HTTP endpoint.
61	*Verify: CRL endpoint reachable from public internet (if external certs) and from all
62	internal clients; OCSP responder uptime > 99.9%.*
63
64	6. Monitor expiry — Key Vault sends events for upcoming expiry. Stream to a dashboard.
65	For AD CS, use a script (`certutil -view`) on a schedule. Track 90/60/30/7 days out.
66	Verify: no cert in production expires unmonitored; alerts fire 60 days before expiry.
67
68	7. Rotation discipline — Plan rotation before issuance, not when expiry approaches.
69	Service teams own renewal automation; PKI team owns CA +

People who liked this also viewed

6 picks

Type