ADFS, WAP and updating their public certificates

Renewing public certificates within an environment is always a bit of a pain – especially when you use the same certificate on a range of different systems and have to update each manually! When you’ve got a number of web-based systems that you publish externally, using a reverse proxy such as a Microsoft Web Application Proxy (WAP) can make the task a little less tedious.

With WAP, you can use a single wildcard certificate to publish any number of web-based services to the public internet. When you need to update the public certificate, you only need to update it in the one place – you don’t need to update each individual web service. In addition, WAP can also act as an Active Directory Federation Services Proxy (ADFS Proxy) – this allows you to present your ADFS infrastructure to the public internet without directly exposing your ADFS server(s).

In general, ADFS and WAP should go hand-in-hand. Internal clients hit the ADFS server directly (via the ADFS namespace), while external clients communicate via the WAP. By doing this, you can also set up different rules in ADFS to define what should happen for external authentication requests, compared to internal authentication requests (e.g: 2-factor auth for external, windows auth for internal).

Now, both ADFS and WAP need to have a public-signed certificate. What happens when those certificates expire? Obviously you need to renew them and update the configuration – which is what prompted me to write this article. Usually this is a pretty simple process – you import the new certificate into the local computer certificate store on each of your ADFS/WAP servers, then update the configuration.

Initially I noticed I was getting the following in the event logs of the WAP server:

I had a look at the certificate on the ADFS server and sure enough, the certificate thumbprint matched the expired certificate on the ADFS server. Since I was using that certificate on the WAP server as well, I needed to update it in both systems. I started by importing the new public wildcard certificate into both the ADFS and WAP servers.

The next step is to update the configuration. For ADFS, you can pull up the ADFS console and go to the Service\Certificate node. From there, you select the ‘Service Communications’ certificate, hit the ‘Set Service Communications Certificate’ link, then follow the wizard. Then in the ADFS event log I started getting:

Whoops, I forgot to give access to the service account for the private key! In the Certificate Management console, locate the public cert, right-click, select ‘All Tasks’ – ‘Manage Private Keys’ and make sure the service account has full access. I restarted the ADFS service (adfssrv) and the ADFS server looked to start up successfully. Or so I thought.

Assuming ADFS was all good, I then proceeded to update the main proxy certificate in WAP. To do this you really only have the option to use a powershell command:

…and of course I was still getting trust errors. In the end I removed and re-added the WAP role to the server (it was a development environment – and since the rules and configuration are stored with ADFS, it’s wasn’t a huge issue). When trying to re-create the trust to the ADFS server via the wizard, I was getting a trust error – along with the following in the event log:

Odd. I could resolve and ping the ADFS server (both directly and via the ADFS namespace) – and the credentials used were an administrator on the remote server. The new certificate was showing correctly in the ADFS console, and the event logs on the ADFS server indicated it was all fine. So I started going through all the config via Powershell instead. After a bit of investigation, I ran the Get-AdfsSslCertificate  command. Despite the ADFS console showing the correct certificate, powershell was still showing the old one!

I ran: Get-ChildItem -path cert:\LocalMachine\My  to get the thumbprint of the new certificate, then Set-AdfsSslCertification thumbprint <newthumbprint>  to set it. I restarted the service with  Restart-Service adfssrv and double-checked the certificate. Ok, NOW we were looking good.

As it turns out, the GUI wizard will update the configuration in the ADFS database, but not the binding on HTTP.sys.

I re-ran the WAP wizard and everything started working correctly.

One other thing to take note of – the above commands are all about updating certificates specifically for ADFS and the ADFS Proxy (WAP) – if you have additional published rules in WAP, you’ll need to update the certificate thumbprint against those as well!

 

Microsoft Exchange Federation Certificates – Keep an eye on the expiry!

I recently had a client experience an issue with their hybrid exchange setup (365/On Premise) – users were suddenly unable to retrieve free/busy and calendar information between the two environments. As it turns out, the certificate used to secure communications to the Microsoft Federation Gateway (MFG) had expired.

Federation certificates within exchange are generally created as part of the federation creation wizard (or the 365 Hybrid Configuration Wizard) – so in most cases, people don’t realise they’ve been created. If you’re not actively monitoring certificate expiry dates on your servers (which you should be!), you may get into the situation where this certificate expires – which results in the federation no longer working.

Why is it important to renew it before it expires? Because if you don’t, you need to remove and re-create the federation – a significantly larger task than the federation certificate renewal process. The reason for needing to re-create the trust is due to the fact that the federation certificate is used to authenticate any changes to the federation – so once it expires you can’t make any changes and have to start from scratch. Lets take a look at the steps involved in both:

Renewing before expiry:

  1. Create a new self-signed federation certificate
  2. Set the new certificate as the ‘Next’ certificate in the federation trust
  3. Wait for AD replication
  4. Test the certificate and trust (Test-FederationTrustCertificate, Test-FederationTrust)
  5. Roll-over the ‘Current’ certificate to the ‘Next’ certificate
  6. Refresh the federation metadata

Renewing after expiry:

  1. Document the existing trust settings (federated domains, federation settings)
  2. Force remove each federated domain from the federation
  3. Remove the federation trust
  4. Wait for AD replication
  5. Create a new self-signed federation certificate
  6. Create a new federation trust
  7. Update the trust organisation information
  8. Configure the required settings in the trust (as per the documentation you created in step 1)
  9. Wait for AD replication
  10. Test the certificate and trust (Test-FederationTrustCertificate, Test-FederationTrust) – it can take 12-48 hours before the trust reports as being no longer expired!
  11. Add each of the federated domains back into the trust (this will involve generating domain ‘Proof’ entries and adding them to your external DNS, then waiting for DNS propagation)

So in short, don’t let your federation certificates expire!