#pki

Read Time:3 Minute, 40 Second

GoDaddy has carried out one of the largest certificate revocation events of the year, pulling more than 404,000 SSL/TLS certificates after discovering that a batch of issued certificates did not line up with its own published certificate policies. The cleanup touched both the GoDaddy and Starfield certificate chains and came with an added complication: the company missed the strict deadline certificate authorities are required to meet when fixing this kind of error.

What went wrongAccording to GoDaddy’s incident disclosure, an outside researcher flagged inconsistencies between certificates the company had issued and the profiles described in Starfield’s Certificate Policy and Certification Practice Statement (CP/CPS) — the rulebook a certificate authority is supposed to follow every time it issues a certificate. The mismatches centered on policy object identifiers (OIDs) and CPS URI qualifiers, metadata fields that tell browsers and other software which issuance rules a certificate was supposed to follow.

Crucially, GoDaddy has characterized this as a paperwork and process failure rather than evidence that private keys were stolen or that certificates were issued to the wrong parties. Once the report was confirmed, GoDaddy paused new certificate issuance, corrected its documentation, and then resumed operations — but a subsequent audit turned up similar inconsistencies in the older, retired Starfield G2 chain as well.

The scale of the falloutThe overwhelming majority of the affected certificates were domain-validated (DV) — the most common and least rigorously vetted certificate type. Breaking down the numbers:

Starfield R1 DV certificates: 208,896 affected

Starfield G2 DV certificates: 187,159 affected

A smaller remainder spread across organization-validated and extended-validation certificates in both chains

That puts the total above 404,000 certificates needing replacement — a population large enough to include certificates protecting government portals, financial institutions, and healthcare organizations, according to GoDaddy’s own outreach records.

A missed deadline made things worseIndustry rules under the CA/Browser Forum’s TLS Baseline Requirements (Section 4.9.1.1) require a certificate authority to revoke a non-compliant certificate within 24 hours, with an absolute outer limit of five days, using the “superseded” revocation reason. GoDaddy began notifying affected customers on October 14 through email, SMS, and phone calls, but by the time the five-day window closed at 23:45 UTC on October 18, only 170,566 certificates — well under half — had actually been revoked.

The company continued working through the backlog, reaching 227,422 revocations by the early hours of October 19, and says it finished revoking the remaining non-compliant certificates on October 21. Missing the original deadline effectively created a second compliance problem on top of the first, since late revocation is itself a violation of baseline requirements that root certificate programs (run by Google, Apple, Microsoft, and Mozilla) take seriously.

What site owners need to doFor administrators whose certificates were swept into this revocation, the practical risk is straightforward: a revoked certificate that is still being served by a web server will eventually trigger browser security warnings, and in some cases block access outright once revocation checks catch up across different browsers and operating systems. GoDaddy has pushed replacement certificates to affected accounts, but the company explicitly warns that having a new certificate sitting in an account is not the same as having it installed and live on the server.

Site owners should check the SSL certificate section of their GoDaddy account, confirm whether they received a replacement notice, and verify — ideally by inspecting the certificate actually being served on their domain, not just the dashboard — that the new certificate is the one in production.

Part of a patternThis is not the first time a major certificate authority has had to scramble through a mass revocation tied to a compliance gap rather than a confirmed key compromise; DigiCert went through a comparable episode following a domain-validation error. Episodes like this tend to reignite debate within the CA/Browser Forum over shortening certificate lifetimes and tightening automated validation, on the theory that shorter-lived certificates reduce the blast radius whenever an issuance error like this one surfaces.

For now, the practical takeaway for IT teams is less about the specific OID mismatch and more about certificate hygiene in general: know which certificate authority issued your certificates, monitor for revocation and expiry notices across all of your domains, and treat “replacement available” messages from any CA as something to act on immediately rather than file away.

Read Time:3 Minute, 12 Second

Browser makers and software maintainers are rapidly withdrawing trust from eight eMudhra intermediate certificate-authority certificates after a researcher demonstrated control of their private signing keys. Because the intermediates connect to roots accepted by major platforms, clients that still trust the affected chains could potentially accept fraudulent certificates as genuine.

The researcher, identified publicly as Wayne, reported the issue to certificate root programs on October 17, 2026. To prove possession without publishing the secrets themselves, the researcher signed a short message with each compromised private key. The corresponding certificates, public keys and signatures were released so independent reviewers could verify the result with standard cryptographic tools.

Why an intermediate CA key mattersA website certificate is usually trusted through a chain: the site certificate is signed by an intermediate authority, which ultimately links to a root embedded in a browser, operating system or application. Possession of an intermediate’s private key may allow an attacker to issue new certificates that vulnerable clients accept under that chain.

That capability does not automatically place an attacker inside a user’s network. But when combined with the ability to intercept or redirect traffic, a forged certificate could support convincing website impersonation and potentially allow encrypted traffic to be read or modified. This is why certificate-authority incidents demand ecosystem-wide action rather than a fix on a single web server.

The public evidence confirms signing capability, not the cause of the exposure. It does not establish that the keys were recovered through a rapid cryptographic break, despite claims circulating online, and it does not prove that forged certificates were used against end users. How the keys became accessible remains publicly unresolved.

Browsers moved quickly to block the chainsMozilla received the report at 20:06 UTC on October 17 and completed a OneCRL blocklist rollout less than three hours later. Standard Firefox configurations could receive that protection without a conventional browser upgrade or restart. Chrome reportedly blocked the certificates the same day, Apple followed on October 19, and Microsoft deployed protection on October 20. eMudhra has revoked the affected intermediates as well.

Mozilla also shipped Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 for environments where settings might prevent OneCRL delivery. NSS 3.131.1 removes the associated signing root from the trust list used by other software. Additional fixed trust bundles include Go 1.27.3 and 1.26.10, Python certifi 2026.10.19, and Rust webpki-roots 1.0.10. Updates for some other ecosystems were still pending when the incident response information was reviewed.

Application trust stores are the long tailCertificate revocation alone is not universal protection. Some programs do not check revocation status reliably, cannot receive browser-maintained blocklists, or ship a private copy of trusted roots. A fully updated browser may reject the affected chain while a command-line client, container image, embedded device or older application continues to accept it.

Update browsers and operating systems across managed endpoints.

Inventory runtimes, containers and applications that bundle their own CA files.

Upgrade language-specific trust packages and rebuild images that pin older bundles.

Use the public incident test chains to check important clients for rejection.

Escalate any unexpected acceptance or suspicious certificate observations to the security team.

Manual removal of roots should be reserved for experienced administrators because trust-store changes can break legitimate connections. Where vendors have published supported releases, those updates provide a safer and more auditable remedy.

The incident illustrates a recurring weakness in public-key infrastructure: emergency browser controls can protect mainstream users quickly, while fragmented software dependencies take longer to converge. Organizations need an inventory of certificate bundles just as they need an inventory of vulnerable libraries. Without it, defenders may patch the visible browser fleet and overlook the services that perform sensitive machine-to-machine connections.

È una delle domande più ricorrenti — e più controverse — tra chi gestisce Active Directory da anni: si può installare il ruolo Certification Authority direttamente su un domain controller? La risposta tecnica è sì, Microsoft lo supporta e Active Directory Certificate Services (AD CS) si integra perfettamente con un DC: template dei certificati, auto-enrollment e pubblicazione funzionano senza intoppi. Ma “supportato” non significa “consigliato”, e la differenza tra le due cose è esattamente il punto su cui vale la pena soffermarsi, perché tocca il cuore della progettazione di una #PKI aziendale.

Perché viene fatto comunque (e quando ha senso)Nella pratica, combinare CA e DC sullo stesso server capita più spesso di quanto si pensi, soprattutto in contesti con risorse limitate:

piccole aziende con uno o due domain controller in totale;

filiali remote con hardware e budget contenuti;

ambienti di laboratorio o di test;

scenari dove il certificato serve solo per usi interni (autenticazione LDAPS, smart card, qualche servizio intranet) senza requisiti di #compliance stringenti.

In questi casi, la strettissima integrazione con Active Directory semplifica davvero il deployment iniziale e riduce il carico amministrativo: non c’è un server aggiuntivo da patchare, monitorare e proteggere separatamente. Dal punto di vista del semplice funzionamento tecnico, non c’è nulla che impedisca questa configurazione.

Il problema: concentrare il rischio in un unico puntoIl motivo per cui la maggior parte delle linee guida di hardening sconsiglia questa combinazione non è un dettaglio tecnico, ma un principio di progettazione della sicurezza: un domain controller compromesso che è anche una CA espone contemporaneamente le credenziali di dominio, l’autenticazione di tutto il dominio, le chiavi private della CA e i diritti di emissione e revoca dei certificati. Un singolo attaccante che ottiene accesso privilegiato a quella macchina ottiene tutto in un colpo.

Ci sono poi due conseguenze meno ovvie, ma altrettanto importanti:

Il contenimento diventa più difficileRicostruire il domain controller da zero dopo un incidente non “ripristina la fiducia” nei certificati già emessi da quella CA: quei certificati restano validi (o da revocare uno per uno) indipendentemente da cosa succede al DC. Viceversa, ripristinare la CA da un #backup non dimostra affatto che la directory sia ancora integra e non compromessa. Sono due problemi di fiducia distinti che, se il ruolo è unico, si trovano intrecciati nello stesso incidente di sicurezza.

Il recovery diventa accoppiatoSe la CA fallisce proprio durante la ricostruzione di un DC (o viceversa), si rischia di bloccare contemporaneamente la revoca urgente di certificati compromessi, il rinnovo e l’enrollment — con impatti diretti su VPN, Wi-Fi aziendale, autenticazione tramite smart card, certificati dei dispositivi e servizi TLS interni. In un’emergenza, avere due sistemi critici che devono essere ripristinati insieme nell’ordine giusto è l’ultima cosa che si vuole gestire sotto pressione.

L’architettura PKI che scala davvero: la gerarchia a due livelliIl design che la maggior parte delle organizzazioni di dimensioni medio-grandi dovrebbe adottare è la classica gerarchia PKI a due livelli, pensata esattamente per separare i ruoli e isolare il rischio:

Root CA offline: non è mai joinata al dominio, viene accesa solo quando serve (tipicamente per emettere o rinnovare i certificati delle CA subordinate e pubblicare le CRL), e l’accesso fisico e logico è estremamente ristretto. È, di fatto, l’ancora di fiducia di tutta la PKI, e per questo resta isolata dal resto #dell’infrastruttura.

Issuing CA aziendale: normalmente un member server joinato al dominio ma non un domain controller. Si occupa dell’enrollment quotidiano, pubblica i certificati, supporta l’auto-enrollment e si integra con AD per i template — ma senza condividere il ruolo con l’autenticazione del dominio.

Su scala enterprise, a questo si aggiungono #storage delle chiavi protetto dove opportuno (HSM o equivalente), ruoli amministrativi distinti tra chi gestisce AD e chi gestisce la PKI, e procedure testate — non solo scritte su un documento — per revoca, sostituzione delle chiavi e disaster recovery.

Come scegliere in base alla dimensione dell’organizzazioneNon esiste una risposta universale: la scelta corretta dipende dal contesto, e la linea guida pratica è questa:

Piccole organizzazioni: combinare CA e DC può essere un compromesso accettabile, a condizione che sia una scelta consapevole e non un effetto collaterale della pigrizia. Serve comunque: backup separati e testati del database della CA e della chiave privata, location di revoca (CRL/AIA) effettivamente raggiungibili, e una sequenza di recovery documentata e provata almeno una volta.

Organizzazioni di medie dimensioni: è il momento di passare a una issuing CA dedicata quando i certificati iniziano a supportare VPN, Wi-Fi, Network Policy Server (NPS) o autenticazione dei dispositivi, quando il volume di auto-enrollment cresce, o quando PKI e Active Directory devono poter essere ripristinati in modo indipendente l’uno dall’altro.

Grandi organizzazioni: qui la separazione dei ruoli non è un “nice to have” ma un requisito di fiducia e resilienza. Un’architettura PKI realmente separata (root offline + issuing CA dedicata, eventualmente più issuing CA per region o per business unit) è lo standard de facto.

Checklist operativa: cosa fare se le cose vanno maleChi si trova a gestire un ambiente con CA e DC combinati — per scelta o per eredità — dovrebbe avere già pronte due procedure di emergenza.

CA fallita su un domain controllerPreservare il sistema guasto e tutti i backup disponibili, senza sovrascrivere nulla prematuramente.

Confermare che un altro DC stia fornendo correttamente AD DS e DNS, per non trovarsi anche senza directory funzionante durante il recovery.

Ripristinare la CA solo da backup verificati come integri.

Verificare che le location AIA e CRL siano effettivamente raggiungibili dai client.

Pubblicare dati di revoca aggiornati, se necessario.

Testare enrollment e validazione dei certificati prima di dichiarare chiuso l’incidente.

Sospetto compromesso della chiave della issuing CAFermare immediatamente l’emissione di nuovi certificati.

Preservare le evidenze per l’analisi forense.

Sostituire il certificato e la chiave della CA emittente.

Identificare e revocare i certificati fraudolenti o potenzialmente compromessi.

Pubblicare informazioni di revoca aggiornate.

Rilasciare nuovi certificati a utenti, dispositivi e servizi impattati.

Un dettaglio spesso sottovalutato: i certificati dei domain controllerIndipendentemente da dove risiede la CA, i certificati emessi per i domain controller devono soddisfare requisiti precisi: supportare sia l’autenticazione server che quella client, includere il nome DNS corretto del DC, avere i key usage adeguati e fare riferimento a una location CRL effettivamente raggiungibile dai client che devono validarli. I requisiti esatti del template variano in base ai servizi coinvolti — LDAPS e sign-in tramite smart card, in particolare, hanno esigenze specifiche che vanno verificate caso per caso.

Cosa fare se si eredita un ambiente con CA e DC già combinatiNon è necessario smontare tutto in un weekend. Microsoft supporta la migrazione di una CA che preserva database, certificati, configurazione e chiavi private, quindi il percorso corretto è trattarla come un vero e proprio progetto PKI pianificato — valutando criticità del business, obblighi di compliance, piani di espansione dei certificati e il livello di rischio accettabile — magari approfittando di un refresh hardware già previsto per farlo con il minimo impatto operativo.

ConclusioneLa domanda “posso installare la CA sul domain controller?” ha una risposta tecnica semplice (sì) e una risposta di design molto più sfumata (dipende, ma per la maggior parte delle organizzazioni in crescita la risposta pratica è no). Il punto da ricordare è che la supportabilità di Microsoft non equivale a una buona architettura: è una scelta che concentra rischio, complica il contenimento degli incidenti e accoppia il recovery di due sistemi critici che, idealmente, dovrebbero poter fallire e essere ripristinati in modo indipendente. Per un laboratorio o una microazienda può essere un compromesso ragionevole, purché documentato; per tutto il resto, una issuing CA dedicata, separata dai domain controller, resta la base di una PKI che tiene quando serve davvero.

Fonte: Petri IT Knowledgebase – Should You Install Certificate Authority on a Domain Controller?