Tag Archive: SSL


Scrap my last post… Today I found I could no longer login to sharepoint and other federated services were acting strangely. I tried to troubleshoot but ultimately gave up.

Finally came the time to see if my weekly VM backups (and nightly incrementals) were actually any good… 15 minutes later and everything’s back to how it was 2 night’s ago!

Screen Shot 2015-04-21 at 15.48.06

Thankfully Veeam worked a treat and ADFS was back working perfectly BUT we still have our expiring SSL warning.

Screen Shot 2015-04-21 at 21.00.32

My theory as to what went wrong before… Whilst I had updated my SSL certificates on my on-premise ADFS server (including the token signing certificate), I think the Office365 hosted servers also need this same matching certificate. So, let’s try a different approach.

This time I followed a different link http://www.kraak.com/?p=190. I started the same way as before, replacing the SSL certificate in IIS. However, I didn’t update the token-signing or token-decrypting certificates in ADFS. Instead I issued the following commands;

Connect-MsolService
Get-MsolFederationProperty -DomainName tickett.net

At this stage, I can essentially see that both the ADFS Server (on-premise) and Microsoft Office 365 (hosted) certificates match;

Screen Shot 2015-04-21 at 21.16.46

At this point I noticed that, not only did they (obviously) bare the old dates, but they also bare the internal server name (and not the FQDN of either my old or new SSL certificates for IIS). This further backs up my theory that using the same certificate for IIS and ADFS yesterday was wrong. And in fact, it appears ADFS generates it’s own certificates when instructed to do so;

Update-ADFSCertificate -CertificateType: Token-Signing -Urgent:$true
Get-MsolFederationProperty -DomainName tickett.net

Screen Shot 2015-04-21 at 21.24.05

Right, we’re part way there. The ADFS Server certificate has now been renewed, but the Microsoft Office 365 certificate now needs to be updated;

Update-MsolFederatedDomain -DomainName tickett.net
Get-MsolFederationProperty -DomainName tickett.net

Bingo, now they both match! Exactly the same sequence of commands now needs to be executed for the token-decrypting certificate;

Update-ADFSCertificate -CertificateType: Token-Decrypting -Urgent:$true
Update-MsolFederatedDomain -DomainName tickett.net

And voila! I can now login perfectly to all my federated/SSO application/sites and Office365 webmail no longer warns me about a certificate approaching expiry.

Advertisements

*EDIT* This turned out to fail, please read the follow-up post; https://tickett.wordpress.com/2015/04/21/second-attempt-updating-adfs-ssl-certificate-on-windows-server-2012-r2/ 

I noticed a warning in Office 365 webmail that my SSL certificate was due to expire soon and hoped updating it would be a trivial task.

As always, I used https://www.startssl.com/ to generate a new certificate. I fired up IIS on the ADFS server and imported the new certificate (Server Certificates, Import). When I tried to bind the certificate to the ADFS https site I received a warning/error about a missing intermediate CA certificate. This was easily fixed by downloading the “Class 2 Intermediate Server CA” certificate from StartSSL and importing into the windows certificate store under Intermediate Certificate Authorities (Launched from the start menu by searching for “Manage computer certificates”);

Screen Shot 2015-04-20 at 17.07.17

Binding to the site in IIS was now successful. However, none of my federated applications were working. Just an ADFS error;

Screen Shot 2015-04-20 at 17.14.57

And some errors to match in the event log;

Screen Shot 2015-04-20 at 17.17.14

On each login attempted I was received the following 3 events;

Event: 111

The Federation Service encountered an error while processing the WS-Trust request.
Request type: http://schemas.microsoft.com/idfx/requesttype/issue

Additional Data
Exception details:
System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)

Event: 1000

An error occurred during processing of a token request. The data in this event may have the identity of the caller (application) that made this request. The data includes an Activity ID that you can cross-reference to error or warning events to help diagnose the problem that caused this error.

Additional Data

Caller:
TICKETT\lee

OnBehalfOf user:

ActAs user:

Target Relying Party:
http://adfs.tickett.net/adfs/services/trust

Device identity:

User action:
Use the Activity ID data in this message to search and correlate the data to events in the Event log using Event Viewer. This Activity ID will also be shown as additional information in the error page when an error occurs in the federation passive Web application.

Event: 364

Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:federation:MicrosoftOnline

Exception details:
Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestSingleSingOnToken(ProtocolContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSsoSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken, SecurityToken& ssoSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
--- End of inner exception stack trace ---
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestSingleSingOnToken(ProtocolContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSsoSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken, SecurityToken& ssoSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)

The earlier Office365 warning did link to a page which also included instructions for updating the certificates within ADFS, so I went ahead and did that too (In ADFS Manager, Set Service Communications Certificate, Add Token-Signing Certificate and Add Token-Decrypting Certificate). But still nothing… restarting didn’t help either.

Eventually I found an article with a few powershell commands; http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2013/11/13/replace-certificates-on-adfs-3-0.aspx

Get-AdfsSslCertificate

Screen Shot 2015-04-20 at 17.24.02

Comparing this to the new certificate, I can see that it doesn’t match;

Screen Shot 2015-04-20 at 17.25.20

Set-AdfsSslCertificate -Thumbprint NEWSSLCERTIFICATETHUMBPRINT

Screen Shot 2015-04-20 at 17.26.18

Despite returning an error message referencing the old SSL certificate, you can see that the new one is now correctly assigned (by issuing the Get-AdfsSslCertificate command again).

And voila, I can now log in to my federated applications.

*EDIT* This turned out to fail, please read the follow-up post; https://tickett.wordpress.com/2015/04/21/second-attempt-updating-adfs-ssl-certificate-on-windows-server-2012-r2/ 

%d bloggers like this: