The Hybrid Certificate Challenge
Hybrid environments don’t just double the number of certificates — they fragment visibility in ways that pure on-prem or pure cloud environments don’t experience.
When your infrastructure spans an on-premises data center, two or three cloud providers, and a handful of SaaS integrations, no single tool or team sees the complete certificate picture. The result is what we call “certificate blind spots” — areas where certificates exist, expire, and cause outages without anyone knowing until it’s too late.
Here’s what we typically find when running certificate discovery across hybrid environments, and how to close those visibility gaps.
The Typical Hybrid Architecture
┌─────────────────────────────────────────────────────────────┐
│ HYBRID ENVIRONMENT │
├──────────────────┬──────────────────┬───────────────────────┤
│ ON-PREMISES │ AWS/AZURE │ EDGE/SAAS │
├──────────────────┼──────────────────┼───────────────────────┤
│ AD CS (Internal) │ ACM (managed) │ CDN certificates │
│ IIS servers │ IAM certificates │ SaaS SAML certs │
│ Exchange │ ELB/ALB certs │ API gateway certs │
│ VPN appliances │ CloudFront │ Partner integrations │
│ Load balancers │ Key Vault │ IoT device certs │
│ Network gear │ AKS/EKS ingress │ Email gateways │
│ RADIUS/NPS │ Lambda (mTLS) │ Reverse proxies │
└──────────────────┴──────────────────┴───────────────────────┘
Each layer has its own certificate management approach (or lack thereof), its own tools, and its own team responsible for renewals.
Discovery Approach: Layer by Layer
Layer 1: On-Premises Discovery
# AD CS - Export all issued certificates
certutil -view -restrict "Disposition=20" -out `
"RequestID,CommonName,NotAfter,CertificateTemplate,RequesterName" `
> adcs-issued.csv
# Windows Certificate Stores - All domain machines
$results = @()
$computers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
Select-Object -ExpandProperty Name
foreach ($computer in $computers) {
try {
$certs = Invoke-Command -ComputerName $computer -ScriptBlock {
Get-ChildItem Cert:\LocalMachine\My |
Select-Object Subject, NotAfter, Issuer, Thumbprint,
HasPrivateKey, EnhancedKeyUsageList
} -ErrorAction Stop
foreach ($cert in $certs) {
$results += [PSCustomObject]@{
Computer = $computer
Subject = $cert.Subject
Expiry = $cert.NotAfter
Issuer = $cert.Issuer
Thumbprint = $cert.Thumbprint
HasKey = $cert.HasPrivateKey
}
}
} catch {
Write-Warning "Cannot reach $computer"
}
}
$results | Export-Csv -Path "onprem-certs.csv" -NoTypeInformation
AWS ACM Coverage vs. Total Certificate Estate
What ACM manages vs. what a typical enterprise actually needs
5%
Covered by ACM
95%
Needs separate management
Layer 2: Cloud Certificate Discovery
AWS
# ACM certificates across all regions
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' -o text); do
echo "=== $region ==="
aws acm list-certificates --region $region \
--query 'CertificateSummaryList[].{Domain:DomainName,ARN:CertificateArn,Status:Status}' \
--output table
done
# IAM server certificates (legacy)
aws iam list-server-certificates --output json
# ELB/ALB listeners with certificates
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' -o text); do
aws elbv2 describe-listeners \
--region $region \
--query 'Listeners[?Certificates].{LB:LoadBalancerArn,Cert:Certificates[0].CertificateArn}' \
--output table 2>/dev/null
done
Azure
# Azure Key Vault certificates
for vault in $(az keyvault list --query '[].name' -o tsv); do
echo "=== Vault: $vault ==="
az keyvault certificate list --vault-name $vault \
--query '[].{Name:name,Expires:attributes.expires,Enabled:attributes.enabled}' \
--output table
done
# App Service certificates
az webapp config ssl list --resource-group "*" \
--query '[].{Name:name,Expiry:expirationDate,Thumbprint:thumbprint}' \
--output table
# Application Gateway certificates
az network application-gateway list \
--query '[].{Name:name,SSLCerts:sslCertificates[].name}' \
--output table
GCP
# GCP managed certificates
gcloud certificate-manager certificates list \
--format="table(name,managed.domains,expireTime,managed.state)"
# GCP load balancer certificates
gcloud compute ssl-certificates list \
--format="table(name,type,expireTime,managed.domains)"
Layer 3: Edge and SaaS Discovery
# CDN certificates (Cloudflare example)
curl -s -H "Authorization: Bearer $CF_TOKEN" \
"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/ssl/certificate_packs" | \
jq '.result[] | {hosts, expires_on, status}'
# External scan of all known endpoints
cat all-endpoints.txt | httpx -silent -tls-grab -json | \
jq '{host: .host, issuer: .tls.issuer_organization,
expiry: .tls.not_after, cn: .tls.subject_cn}'
What We Typically Find
Finding Pattern 1: The Visibility Gap
Certificates by Discovery Source
┌──────────────────────────────────────────────────────────┐
│ │
│ Known to IT: 142 certificates │
│ AD CS database: 287 certificates │
│ Network scan: 423 certificates │
│ Cloud APIs: 189 certificates │
│ CT Logs: 312 certificates (external only) │
│ │
│ TOTAL UNIQUE: 634 certificates │
│ IT's visibility: 22% of actual landscape │
│ │
└──────────────────────────────────────────────────────────┘
The average hybrid enterprise knows about fewer than 25% of its total certificates.
Finding Pattern 2: The CA Sprawl Problem
| Source | CA Used | Managed By | Renewal Process |
|---|---|---|---|
| On-prem servers | Internal CA (AD CS) | IT Ops | Auto-enrollment (partial) |
| Public websites | DigiCert | Security team | Manual |
| AWS workloads | Amazon (ACM) | Cloud team | Auto-managed |
| Azure workloads | DigiCert (via KV) | Cloud team | Semi-auto |
| Dev environments | Let’s Encrypt | DevOps | certbot cron |
| CDN | Cloudflare | Marketing | Fully managed |
| VPN | Sectigo | Network team | Manual |
| Email gateway | GlobalSign | Email admin | Manual |
8 different CAs, 6 different teams, 4 different renewal processes.
Finding Pattern 3: Cloud-Managed Doesn’t Mean Covered
A common misconception: “AWS ACM handles our certificates automatically.”
Reality check:
AWS ACM Coverage Analysis:
━━━━━━━━━━━━━━━━━━━━━━━━━━
Total AWS certificates needed: 189
Managed by ACM: 92 (49%)
Self-managed on EC2: 54 (29%)
In EKS/containers: 28 (15%)
Lambda/API Gateway: 15 (8%)
ACM auto-renews: ✅ Only the 92 it manages
EC2 self-managed: ❌ Your responsibility
EKS ingress certs: ❌ Depends on cert-manager config
Lambda custom domains: ⚠️ Partially managed
Finding Pattern 4: Internal Certificate Overload
AD CS Issued Certificates (Last 12 Months):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Computer authentication: 2,847
User authentication: 1,234
Web server (IIS): 156
IPSec: 89
Code signing: 12
EFS: 45
Custom templates: 67
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TOTAL: 4,450
Auto-enrolled: 3,891 (87%)
Manually requested: 559 (13%)
Expired without renewal: 234 (5.3%)
Even with auto-enrollment, 5.3% of certificates expired without renewal. For 4,450 certificates, that’s 234 potential service disruptions per year.
Finding Pattern 5: The Shadow Certificate Problem
Certificates nobody in security knows about:
Shadow Certificate Sources:
• Developer-created Let's Encrypt certs: 34
• Self-signed certificates in production: 18
• Certificates from previous vendor: 12
• IoT device certificates (vendor-issued): 45
• Legacy application embedded certificates: 8
• Partner-issued client certificates: 23
─────────────────────────────────────────────────────
Total "shadow" certificates: 140
Common Blind Spots in Hybrid Discovery
| Blind Spot | Why It’s Missed | Risk |
|---|---|---|
| Kubernetes ingress certs | Dynamic, namespace-scoped | High — outages in microservices |
| IoT/OT device certs | Air-gapped networks | Medium — device authentication failures |
| CI/CD pipeline certs | Short-lived, created dynamically | Low — but can break deployments |
| SaaS SAML certificates | Managed in vendor portal | High — SSO breaks completely |
| Email gateway certs | Managed by messaging team | Medium — mail delivery failure |
| Database TLS certs | DBA-managed, internal | High — application connectivity |
| Service mesh certs (mTLS) | Auto-rotated by Istio/Linkerd | Low — usually self-healing |
| Load balancer client certs | Network team managed | High — B2B integration failure |
Building Hybrid Visibility
Architecture for Complete Coverage
┌─────────────────────────────────────────────────────────┐
│ UNIFIED VISIBILITY LAYER │
│ (CLM Platform / Certificate Inventory) │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Network │ │ Cloud │ │ API │ │
│ │ Scanner │ │ Connector │ │ Integrator│ │
│ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │
│ │ │ │ │
├────────┼────────────────┼───────────────┼───────────────┤
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ On-Prem │ │ AWS/ │ │ CDN/ │ │
│ │ Network │ │ Azure/ │ │ SaaS/ │ │
│ │ AD CS │ │ GCP │ │ Partners│ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────┘
Unified Discovery Checklist
☐ On-Premises
☐ AD CS database export (all templates)
☐ Network scan (all RFC1918 ranges, ports 443,8443,636,3389)
☐ Windows cert store inventory (all servers)
☐ Load balancer certificate lists (F5, Citrix, HAProxy)
☐ Network appliance certs (firewalls, VPN concentrators)
☐ Cloud
☐ AWS ACM (all regions)
☐ AWS IAM server certificates
☐ Azure Key Vault (all vaults)
☐ Azure App Service certificates
☐ GCP Certificate Manager
☐ Kubernetes secrets (type: kubernetes.io/tls)
☐ Edge/External
☐ CT log query (all company domains)
☐ CDN certificates (Cloudflare, Akamai, Fastly)
☐ SaaS SAML/SSO certificates
☐ Partner-facing integration certificates
☐ DNS-based discovery (all registered domains)
☐ Specialty
☐ Code signing certificates
☐ Email/S-MIME certificates
☐ IoT device certificates
☐ Database TLS certificates
☐ Service mesh certificates
The Path from Discovery to Management
Discovery is step one. The progression looks like this:
Stage 1: Discovery → "What do we have?"
Stage 2: Inventory → "Where is everything?"
Stage 3: Risk Assessment → "What's at risk?"
Stage 4: Monitoring → "Are we being alerted?"
Stage 5: Automation → "Can this handle itself?"
Stage 6: Governance → "Is everything in policy?"
Most organizations doing their first hybrid discovery are at Stage 1. The goal is to reach Stage 4 (monitoring) within 30 days and Stage 5 (automation) within 90 days.
Metrics That Matter Post-Discovery
| Metric | Target | Why |
|---|---|---|
| Certificate visibility | >95% | Can’t manage what you can’t see |
| Owner assignment rate | 100% | Accountability for renewals |
| Auto-renewal coverage | >80% | Reduce manual effort |
| Mean discovery-to-inventory time | <24 hours | New certs tracked quickly |
| Expiry alert coverage | 100% of production | No surprise outages |
| Orphaned certificate count | Trending to 0 | Clean up unnecessary risk |
About QCecuring
QCecuring specializes in hybrid certificate discovery and lifecycle management. Our platform connects to on-premises CAs, cloud providers, and network infrastructure to deliver unified visibility across your entire certificate landscape — regardless of where certificates live.
Tags: hybrid environment, certificate discovery, multi-cloud, on-premises, cloud security, AWS ACM, Azure Key Vault, certificate sprawl, visibility gap, CLM, enterprise PKI