1 15/04/2026 8 min

Quando un client SCCM non si registra correttamente in PKI, il problema quasi mai è “il certificato” in senso generico. Di solito il guasto sta in uno di questi punti: template emesso male, EKU mancanti, subject/UPN non coerenti, CRL non raggiungibile, catena non fidata, oppure IIS/management point che non accetta il certificato del client. La strada giusta è verificare il flusso end-to-end: identità del client, validità della CA, pubblicazione della CRL, binding su SCCM e log del client.

Classificazione del problema

Si tratta di troubleshooting su ambiente Microsoft SCCM con componente PKI. L’impatto va trattato come produzione fino a prova contraria, perché una registrazione PKI fallita può bloccare policy, inventory, compliance e distribuzione applicativa.

Stato atteso vs osservato

Atteso: il client ottiene un certificato valido per SCCM, lo presenta al management point e completa l’auth HTTPS senza errori nei log.

Osservato: il client resta in stato non registrato, usa fallback HTTP o mostra errori di autenticazione/certificato nei log come ClientIDManagerStartup.log, CCMHTTPS.log, ClientLocation.log o LocationServices.log.

Dove si rompe davvero il flusso PKI

La registrazione PKI di SCCM non è un singolo check: è una catena. Il client deve avere un certificato valido con EKU corretti, il management point deve fidarsi della CA, il client deve poter raggiungere CRL e AIA, e la configurazione del sito deve accettare HTTPS o mixed mode nel modo previsto. Se uno solo di questi passaggi fallisce, la registrazione può degradare o fermarsi senza messaggi espliciti nel console side.

1. Certificato client non conforme

Il caso più comune è un certificato emesso ma non adatto a SCCM. I sintomi tipici sono la presenza del certificato in certlm.msc o certmgr.msc, ma il client continua a non autenticarsi. Controlla che il certificato abbia almeno Client Authentication nell’EKU, che la chiave privata sia presente e che il subject o l’UPN rispettino la logica di auto-enrollment definita in AD CS.

Verifica rapida con PowerShell:

Get-ChildItem Cert:\LocalMachine\My |
  Select-Object Subject, Thumbprint, NotAfter, EnhancedKeyUsageList

Se l’EKU non include l’uso client auth, il certificato va rigenerato con il template corretto. Non conviene “forzare” SCCM su un certificato sbagliato: il rischio è creare un falso positivo temporaneo e poi perdere la registrazione al rinnovo.

2. CRL o AIA non raggiungibili

Molti ambienti sembrano sani finché il client non prova a validare la catena. Se la CRL è pubblicata su un URL non accessibile dal client, la validazione fallisce e SCCM interpreta il certificato come non affidabile. Questo succede spesso con laptop fuori rete, subnet isolate o ambienti dove la PKI è stata progettata solo per la LAN interna.

Controlla i punti di distribuzione CRL e AIA nel certificato con:

certutil -dump "C:\path\to\client.cer"

Se la CRL è su HTTP, apri l’URL da un endpoint reale che simuli il client. Se l’URL non risponde o restituisce redirect/403, il problema è nella pubblicazione, non in SCCM.

3. Management point non configurato per HTTPS nel modo atteso

Il client può avere un certificato perfetto e fallire comunque se il management point non è configurato per accettarlo. Qui si verifica spesso una discrepanza tra il sito SCCM e IIS: binding errato, certificato server non valido, oppure MP pubblicato in HTTPS ma con requisiti di autenticazione non allineati.

Il controllo va fatto su IIS e sui log del server. Se il sito usa HTTPS, verifica il binding 443 e il certificato server associato. Se usi un Application Request Routing, load balancer o reverse proxy, controlla che il certificato client arrivi intatto e che non venga terminato troppo presto a monte.

4. Template AD CS o auto-enrollment incoerenti

Molti ambienti si rompono dopo un cambio innocuo sul template. Un template duplicato può perdere il flag di Supply in the request, cambiare il subject name, rimuovere l’EKU corretto o restringere i permessi di enrollment. Il risultato è che il client riceve un certificato formalmente valido ma non adatto al ruolo SCCM.

Nel domain controller o nella CA, controlla il template pubblicato e i permessi di enrollment. Se il certificato viene distribuito via auto-enrollment, verifica anche la GPO che abilita la registrazione automatica e la presenza del criterio sul computer object corretto.

Verifiche immediate

Prima di cambiare qualsiasi cosa, raccogli evidenza minima. In SCCM la differenza tra “ipotesi plausibile” e “causa reale” sta nei log giusti, non nel tentativo casuale di reinstallare il client.

1. Sul client apri C:\Windows\CCM\Logs\ClientIDManagerStartup.log e cerca errori di certificato, enrollment o identità.

2. Verifica la presenza del certificato in store macchina:

certlm.msc

3. Controlla lo stato della catena e della revoca:

certutil -verify -urlfetch "C:\path\to\client.cer"

4. Sul management point esamina i log lato server, tipicamente in C:\Program Files\SMS_CCM\Logs\ o nel percorso log configurato dal sito, cercando rifiuti TLS, handshake falliti o problemi di autenticazione del client.

5. Valida il servizio IIS e il binding HTTPS del management point:

netsh http show sslcert

Se il comando mostra un certificato diverso da quello atteso, il problema è nel binding e non nel client.

Soluzione consigliata passo-passo

La correzione più sicura è partire dal punto più vicino all’evidenza e procedere in modo reversibile. Non toccare SCCM e CA insieme se non hai già identificato il guasto: altrimenti perdi la possibilità di attribuire il fix a una sola modifica.

1. Conferma il certificato usato dal client. Dal client, identifica thumbprint, subject ed EKU. Se il certificato non è quello previsto, rimuovi solo il certificato errato se è chiaramente un duplicato o un residuo di test. Se è il certificato di produzione, non cancellarlo: prima verifica il template e la CA.

Get-ChildItem Cert:\LocalMachine\My |
  Format-List Subject, Thumbprint, NotAfter, EnhancedKeyUsageList, HasPrivateKey

2. Verifica la CRL dal punto di vista del client. Se il client non riesce a raggiungere la CRL, pubblicala in un URL accessibile o correggi firewall, proxy e DNS. Questo è un fix strutturale, non un workaround. La mitigazione temporanea può essere un test su rete interna, ma non va usata come soluzione finale.

Esempio di controllo rapido della reachability:

curl -I http://pki.example.local/CertEnroll/ca.crl

Atteso: HTTP/1.1 200 OK o comunque risposta raggiungibile. KO: timeout, 404, 403, redirect anomalo.

3. Correggi il template AD CS se manca l’EKU corretto. Se il template non include Client Authentication, duplica il template, correggi i campi necessari e ripubblicalo. Non modificare il template live senza aver salvato una copia delle impostazioni, perché il rollback deve essere immediato.

Checklist minima del template:

  • EKU con Client Authentication
  • Subject name coerente con la policy
  • Permessi di enrollment per il gruppo computer corretto
  • Validità e rinnovo compatibili con la policy aziendale

4. Allinea il management point. Se il client è corretto ma il MP rifiuta la connessione, verifica il binding IIS, il certificato server e la configurazione del sito SCCM. Se hai un load balancer, controlla che non stia terminando TLS in modo incompatibile con l’autenticazione richiesta dal MP.

Un controllo utile è confrontare il certificato presentato dal server con quello configurato in IIS e con quello atteso in SCCM. Se non coincidono, il problema è di binding o di pubblicazione, non del client.

5. Forza un refresh controllato del client. Dopo la correzione, riavvia i servizi SCCM del client o esegui un ciclo di policy aggiornato. Evita la reinstallazione completa del client come primo tentativo: è più rumorosa, più lenta e spesso nasconde il difetto reale.

Restart-Service CcmExec

Se necessario, riavvia anche il servizio del sistema di enrollment o pulisci solo il cache path dell’agente, ma soltanto dopo aver salvato i log.

Controlli finali / rollback

Dopo la correzione, devi vedere tre segnali coerenti: il certificato è presente e valido, il client completa la connessione verso il management point, e i log non mostrano più errori di trust o autenticazione. Il controllo finale non è “sembra andare”: è un riscontro oggettivo nei log e nello stato del client.

Verifiche finali consigliate:

  1. Controlla ClientIDManagerStartup.log e CCMHTTPS.log: nessun errore di certificato o handshake.
  2. Verifica che il client compaia come attivo e managed nella console SCCM.
  3. Controlla che il management point riceva richieste dal client e non registri più rifiuti TLS.
  4. Conferma che la CRL resti raggiungibile anche fuori dalla subnet amministrativa.

Rollback: se hai modificato il template, ripristina la versione precedente solo se hai una copia esportata o documentazione del settaggio precedente. Se hai cambiato il binding IIS, riassociare il certificato precedente è il rollback più rapido. Se hai toccato GPO o auto-enrollment, disabilita temporaneamente la policy solo per il gruppo di test, non per tutta la foresta.

Assunzione: il problema riguarda un client domain-joined con infrastruttura AD CS e management point SCCM esposti in HTTPS o in modalità mista; se l’ambiente usa un reverse proxy o una PKI cross-forest, va verificata anche la catena di trust tra i domini.

Nota pratica su cosa non fare

Non usare la reinstallazione del client come primo rimedio. Non disabilitare la verifica CRL in modo permanente. Non cambiare template, IIS e configurazione SCCM nello stesso momento senza un piano di rollback. In PKI, i fix rapidi che saltano la validazione quasi sempre tornano a presentarsi al rinnovo o al primo cambio di rete.

Se vuoi una diagnosi più precisa, i tre elementi che chiudono il gap sono: estratto di ClientIDManagerStartup.log, output di certutil -verify -urlfetch sul certificato client e configurazione del binding HTTPS del management point. Con questi tre dati si separa quasi sempre il problema di certificazione da quello di pubblicazione SCCM.