Problem with renewing the federation certificate

Check the Exchange server’s WinHTTP and Exchange-specific proxy configuration next, because this exact Windows Live connection error is documented when the server cannot reach Microsoft federation endpoints through the configured proxy path—even when TLS 1.0/1.1 are disabled and the firewall generally permits outbound traffic.^1^

1. Check the effective proxy path

Run these commands from every Exchange SE server that can execute the federation operation:

Get-ExchangeServer |
    Format-Table Name,InternetWebProxy -Auto

netsh winhttp show proxy

Interpret the results as follows:

• Your organization requires an outbound proxy: confirm that both WinHTTP and InternetWebProxy point to a working proxy and that it allows the required Microsoft endpoints.
• No proxy is required: unexpected or obsolete proxy values can route Exchange traffic incorrectly. Do not clear them until their purpose has been confirmed.
• A PAC file is used: verify what WinHTTP actually resolves; browser connectivity alone does not prove that Exchange’s server-side HTTP path works.

If a proxy is required and InternetWebProxy is missing or incorrect, configure it on each applicable server:

Set-ExchangeServer "EXCH01" `
    -InternetWebProxy "http://proxy.contoso.com:8080"

Configure the equivalent WinHTTP proxy through your normal server/network-management process. Exchange uses WinHTTP for HTTP/HTTPS operations, so browser proxy settings alone may not be sufficient.^2^

Have the network team check the proxy logs for the failed publication timestamp. Permit the required Microsoft 365 and identity/federation destinations over TCP 443; the published endpoint list includes nexus.microsoftonline-p.com, Microsoft identity endpoints, and Exchange Online destinations.^3^

If HTTPS inspection is enabled, conditionally test a narrowly scoped inspection bypass for those Microsoft destinations. A firewall “allow” can still coexist with a TLS session being terminated by a proxy or inspection device.

2. Verify certificate distribution before publishing

Since the certificate and DNS proof are already configured, do not recreate them. Verify that the new federation certificate has reached every Exchange server:

$Servers = Get-ExchangeServer
$Servers | ForEach-Object {
    Get-ExchangeCertificate -Server $_ |
        Where-Object {$_.Services -match 'Federation'}
} | Format-List Identity,Thumbprint,Services,Subject

Also run:

Test-FederationCertificate
Get-FederationTrust |
    Format-List Name,OrgCertificate,OrgNextCertificate

Do not publish until the intended next-certificate thumbprint is present across all servers. Microsoft requires this check before promoting the next certificate.^4^

After correcting the outbound path and confirming distribution, publish it:

Set-FederationTrust -Identity "Microsoft Federation Gateway" `
    -PublishFederationCertificate

Then validate the result:

Get-FederationTrust | Format-List *priv*
Test-FederationTrust -UserIdentity [Email]

OrgPrivCertificate should contain the new thumbprint, while OrgPrevPrivCertificate should contain the replaced certificate’s thumbprint.^5^

3. If the current federation certificate has already expired

Check it explicitly:

Get-ExchangeCertificate `
    -Thumbprint (Get-FederationTrust).OrgCertificate.Thumbprint |
    Format-Table Thumbprint,NotAfter -Auto

If it is already expired, Microsoft documents a different recovery path: remove the federated domains, remove the trust, and recreate it. This is disruptive, so record the existing trust and domain configuration first.^5^

Get-FederatedOrganizationIdentifier |
    Format-List AccountNamespace,Domains

# Remove non-primary domains first, then the primary domain last.
Remove-FederatedDomain -DomainName "domain.example" -Force

Remove-FederationTrust "Microsoft Federation Gateway"

Afterward, recreate the federation trust, add the federated domains again, publish the new DNS proof, and validate with Test-FederationTrust. Do not use this rebuild path if the current certificate remains valid; first resolve the outbound connection failure and complete the normal publication.

References

1. The underlying connection was closed error - Exchange
2. Certificate status could not be determined error generated because revocation check failed when importing a non-Microsoft certificate
3. Microsoft 365 URLs and IP address ranges
4. Set-FederationTrust (ExchangePowerShell) | Microsoft Learn
5. Renew the federation certificate