The Local FQDN certificate warning during a second Exchange 2019 installation typically occurs because the server cannot validate the internal domain name against the issued certificate. This happens when the certificate’s Subject Alternative Name (SAN) does not include the specific Fully Qualified Domain Name of the new server, or when the local DNS records do not resolve correctly to the internal IP address.
Understanding the Certificate Validation Process
Exchange Server relies heavily on Secure Sockets Layer (SSL) certificates for secure communication between clients and the server. During installation, the setup wizard validates that the certificate assigned to services like IIS, SMTP, and IMAP is valid for the server's hostname. If you are installing a second server in an existing organization, the certificate must be trusted by all servers and clients within the Active Directory forest.
The warning appears because the setup process checks the certificate chain and the subject names. If the certificate was issued for the first server's FQDN but not for the second server's FQDN, the validation fails. Additionally, if the internal DNS does not have an A record for the new server's FQDN pointing to its local IP, the certificate validation may fail due to name mismatch errors. It is crucial to ensure that the certificate contains all necessary hostnames in its SAN field before proceeding with the installation.
Verifying DNS Resolution
Before addressing the certificate itself, you must confirm that the network infrastructure supports the new server's identity. Incorrect DNS configuration is a common root cause for this warning. You need to verify that the new server can resolve its own FQDN and that external clients can also resolve it internally.
Open PowerShell on the new Exchange server and run the following command to test resolution:
Resolve-DnsName -Name "YourServerFQDN" -Type A
Replace "YourServerFQDN" with the actual fully qualified domain name of the second server. The output should show an A record pointing to the server's local IP address. If the record is missing or points to an incorrect IP, you must update your internal DNS zone. Log into your DNS management console, locate the forward lookup zone for your domain, and create or modify the A record for the new server. Ensure that the record is replicated across all DNS servers in your environment. After updating DNS, flush the DNS cache on the Exchange server using
ipconfig /flushdns to ensure immediate effect.
Requesting and Installing the Correct Certificate
If DNS resolution is correct, the issue likely lies with the certificate content. You need a certificate that includes both the first and second server's FQDNs in the Subject Alternative Name extension. Standard single-name certificates will not suffice for multi-server deployments.
Generate a new certificate request from the Exchange Management Shell. Use the
New-ExchangeCertificate cmdlet to create a request that includes all required hostnames. Specify the services that require the certificate, such as IIS, SMTP, and POP. Once the request is generated, submit it to your internal Certificate Authority (CA). Ensure that the CA template allows for SAN entries and that the private key is marked as exportable if needed for future migrations.
After the CA issues the certificate, import it into the local store of the new Exchange server. Use the
Import-ExchangeCertificate cmdlet to install the certificate. Then, assign the certificate to the required services using the
Enable-ExchangeCertificate cmdlet. Verify that the thumbprint matches the one expected by the installation wizard. Restart the relevant Exchange services to ensure they pick up the new certificate.
Checking Certificate Trust Chain
Even with the correct SAN entries, the certificate must be trusted by the entire organization. The issuing CA's root certificate must be present in the Trusted Root Certification Authorities store on all Exchange servers and client machines. If the trust chain is broken, the validation will fail.
Export the root CA certificate from your Certificate Authority and import it into the local computer's trusted root store on the new Exchange server. Repeat this process for any other Exchange servers in the farm to maintain consistency. Use the Microsoft Management Console (MMC) with the Certificates snap-in to manage these stores. Navigate to
Certificates - Local Computer >
Trusted Root Certification Authorities >
Certificates and import the root CA file.
Additionally, check for any intermediate certificates. If your CA uses an intermediate CA, ensure that the entire chain is installed. A missing intermediate certificate can cause validation errors even if the root is trusted. You can view the full chain in the certificate properties under the
Certificate Path tab. Ensure there are no yellow warnings or red crosses indicating broken links.
Finalizing Installation Steps
Once DNS, certificate content, and trust chains are verified, retry the Exchange installation. The setup wizard should now pass the certificate validation step without warnings. If the warning persists, check the event logs on the Exchange server for detailed error messages related to certificate validation. Look for events in the
Application log source
MSExchange Setup. These logs often provide specific reasons why the certificate was rejected, such as expiration dates or revocation status.
Ensure that the time synchronization on the new server is accurate. Certificate validity checks rely heavily on correct system time. If the server clock is skewed, certificates may appear expired or not yet valid. Configure Windows Time Service to sync with the domain controller. This simple step can resolve many cryptic certificate errors.
Frequently Asked Questions
Can I use a self-signed certificate for production Exchange servers?
Self-signed certificates are not recommended for production environments because they lack a trusted third-party issuer. Clients and other servers will display security warnings, which can disrupt user experience and automated processes. Always use a certificate issued by an internal or public Certificate Authority for Exchange deployments.
What if my Certificate Authority does not support SAN entries?
Most modern Windows Server CA templates support Subject Alternative Names. If your current template does not allow SANs, you must modify the certificate template settings or create a new one. Contact your PKI administrator to ensure the template is configured to include multiple hostnames in the certificate request.
How do I verify the certificate is assigned to the correct services?
Run the
Get-ExchangeCertificate cmdlet in PowerShell to list all certificates. Check the
Services column to see which certificates are enabled for IIS, SMTP, etc. If the correct certificate is not listed there, use
Enable-ExchangeCertificate to assign it manually.
Does the certificate need to be renewed when adding more servers?
Yes, every time you add a new server to the Exchange organization, you must update the certificate to include the new server's FQDN in the SAN. Failure to do so will result in connection failures and warnings similar to those encountered during installation. Plan your certificate lifecycle to accommodate organizational growth.
Why does the warning persist after installing the correct certificate?
This usually indicates a caching issue or a DNS propagation delay. Restart the World Wide Web Publishing Service and the MSExchange Front End Transport Service to clear cached certificate references. Also, ensure that all DNS servers have updated their zones and that the Exchange server has flushed its local DNS cache.