Certificati Exchange: un 500.19 e un parametro sparito

Tre cose sono andate storte fra certificati e directory virtuali. Una era un parametro che non esiste più, una una macchina che non poteva usare la strada normale per ottenere un certificato, e una un errore IIS che con la configurazione di IIS non c’entrava niente.

Il parametro che è stato rimosso

Il parametro compare ancora in parecchia documentazione e nella maggior parte dei tutorial, perché nessuno torna indietro a riscrivere una guida che funzionava. La forma corretta raccoglie la richiesta in una variabile e scrive il file a parte:

$certrequest = New-ExchangeCertificate -GenerateRequest `
    -SubjectName "cn=<fqdn del server>" `
    -DomainName "<fqdn del server>" `
    -PrivateKeyExportable $true

$certrequest | Set-Content -Path "C:\CertRequest.req"

Un certificato per una macchina fuori dal dominio

Il server Trasporto Edge ha bisogno di un certificato per il canale TLS verso l’organizzazione interna. Non è membro del dominio, quindi non può usare la registrazione automatica via criteri di gruppo: quel meccanismo si fonda proprio sull’appartenenza al dominio.

La strada è la registrazione web di AD CS, con richiesta manuale.

Import-ExchangeCertificate `
    -FileData ([System.IO.File]::ReadAllBytes("C:\certnew.cer"))

Get-ExchangeCertificate | Format-List Subject,Services,Thumbprint
Enable-ExchangeCertificate -Thumbprint "<impronta>" -Services SMTP

I servizi associabili sono IIS (OWA, ECP, EWS, MAPI, ActiveSync, Autodiscover), SMTP (connettori di trasporto), IMAP e POP. Un certificato può servirne più d’uno insieme.

Perché al perimetro serve davvero

Il server Cassette postali e un Edge sottoscritto parlano in TLS reciproco con autenticazione direct trust. La chiave pubblica del certificato autofirmato dell’Edge viene esportata nel file di sottoscrizione, ed è quella a stabilire la fiducia iniziale.

Un certificato emesso correttamente e associato a SMTP è quindi il presupposto del canale su cui viaggerà EdgeSync, non un irrobustimento facoltativo da fare dopo.

Un nome, tre livelli

Il 500.19 che non era un problema di IIS

icacls "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess" `
    /grant "IIS_IUSRS:(OI)(CI)RX" /T

iisreset

(OI)(CI) propaga l’eredità a oggetti e contenitori, RX concede lettura ed esecuzione, /T applica ricorsivamente.

La parte interessante è dove puntava l’errore. Un 500.19 dice «file di configurazione», quindi l’istinto è andare a leggere il web.config, poi la configurazione di IIS, poi le impostazioni delle directory virtuali in Exchange. Erano tutte corrette. A essere rotto era il file system sotto, e nell’errore i permessi non compaiono.

Un limite dichiarato

Per il server Exchange interno non è stato emesso nessun certificato pubblico, e il motivo è strutturale più che di fatica: un certificato pubblico richiede di dimostrare la proprietà di un dominio pubblico registrato, che il laboratorio non aveva.

Le tre lezioni, in breve

Verifica la versione, non il tutorial. Un parametro che sparisce impiega anni a sparire dalle guide che lo usano.

Un nome scritto una volta è un nome da cui dipendi tre volte. Suffisso, record DNS, oggetto del certificato: sbaglialo in un posto e si rompe in un altro.

Leggi dove punta l’errore, poi guarda uno strato più sotto. Un 500.19 accusa la configurazione. La configurazione era giusta, il file system no.