Guides / windows-server

Exchange certificates: a 500.19 and a parameter that vanished

A cmdlet parameter removed for security, a certificate for a machine outside the domain, and an IIS error whose real cause was NTFS permissions.

Three things went wrong around certificates and virtual directories. One was a parameter that no longer exists, one was a machine that could not use the normal enrolment path, and one was an IIS error that had nothing to do with IIS configuration.

The parameter that was removed

The parameter still appears in a great deal of documentation and in most tutorials, because nobody goes back to rewrite a working guide. The correct form collects the request into a variable and writes the file separately:

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

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

Check

A cmdlet that does not recognise a parameter you know is correct is almost always a cmdlet that changed. The check costs seconds and settles it:

Get-Help New-ExchangeCertificate -Full

Run it on the machine you are actually using — not on the documentation site, which may be describing a different build.

A certificate for a machine outside the domain

The Edge Transport server needs a certificate for the TLS channel towards the internal organisation. It is not a domain member, so it cannot use group-policy autoenrolment — that mechanism is built on domain membership.

The way through is AD CS web enrolment, with a manual request.

Generate the request on the Edge server with the sequence above.
Submit the .req through the certification authority’s web enrolment page.
Download the issued certificate.
Import it and bind it to the service.

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

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

The bindable services are IIS (OWA, ECP, EWS, MAPI, ActiveSync, Autodiscover), SMTP (transport connectors), IMAP and POP. One certificate can serve several at once.

Why the perimeter needs one at all

The Mailbox server and a subscribed Edge server talk over mutual TLS with direct trust. The public key of the Edge server’s self-signed certificate is exported into the subscription file, and that is what establishes the initial trust.

A correctly issued certificate bound to SMTP is therefore the precondition for the channel EdgeSync will run over — not an optional hardening step to do later.

One name, three layers

The 500.19 that was not an IIS problem

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

iisreset

(OI)(CI) propagates inheritance to objects and containers, RX grants read and execute, /T applies recursively.

The interesting part is where the error pointed. A 500.19 says “configuration file”, so the instinct is to go and read web.config, then the IIS configuration, then the virtual directory settings in Exchange. All of them were fine. What was broken was the filesystem underneath, and nothing in the error mentions permissions.

A declared limit

No public certificate was issued for the internal Exchange server, and the reason is structural rather than a matter of effort: a public certificate requires proving ownership of a registered public domain, which the lab did not have.

The three lessons, compressed

Verify the version, not the tutorial. A parameter that disappears takes years to disappear from the guides that use it.

A name written once is a name depended on three times. Suffix, DNS record, certificate subject: get it wrong in one place and it breaks somewhere else.

Read where the error points, then look one layer down. A 500.19 blames configuration. The configuration was correct and the filesystem was not.