Markm Posted August 29, 2019 Share Posted August 29, 2019 Hi all, First post here. I have recently updated the Certificate on our ADFS server as we are setting up Single Sign On. After re-importing the IDP Meta Data I get the following error when logging in: The public certificate used for signing the assertion is not flagged as a signing certificate for the service provider If i reverse the process it goes back to working. Unfortunately the old certificate expires on 4th Sept. There is a message i get when changing the new certificate to the Primary (attached). Be grateful if anyone can provide any guidance. Link to comment Share on other sites More sharing options...
James Ainsworth Posted August 29, 2019 Share Posted August 29, 2019 Hi Mark, I found this wiki article which may help lead you to some of the information that you need. There are also other customer posts that may have additional information to help troubleshoot your issue. Link to comment Share on other sites More sharing options...
James Ainsworth Posted August 29, 2019 Share Posted August 29, 2019 Link to comment Share on other sites More sharing options...
Gerry Posted August 29, 2019 Share Posted August 29, 2019 @Markm Having checked our code, the error message is telling you that the public certificates we have (these are the certificate(s) we import from your public meta data and hold in our database) that was used to sign the assertion is not a certificate that was flagged as a signing certificate when it was created. If you look at the certificate we hve imported into our system under the SSO Profile you should see the certificate where the "Signing" column is set to false.... this is why. You should be able to re-generate your public certs and mark them as signing certs like your previous ones and it should all start working. You can see in the screen below, the signing is set to 'true' which is what you want. I dont know much about ADFS so I cannot really guide you as to what you need to do there but the standard X509 cert needs to be flagged as a signing cert, your AD expert should be able to help with that. Gerry Link to comment Share on other sites More sharing options...
Gerry Posted August 29, 2019 Share Posted August 29, 2019 @Markm One other thing I should mention, if you need an emergency fix, under the SSO profile (like the image above), there is a switch labelled "Validate Certificate", if you turn that switch off, our system will not perform that check when you are authenticating, and so assuming there is nothing else wrong it should start working. HOWEVER, I WOULD NOT RECOMMEND YOU RUN IN PRODUCTION LIKE THIS FOR OBVIOUS REASONS, but for testing/verifying the issue it will give you some further guidance. Gerry Link to comment Share on other sites More sharing options...
Markm Posted August 29, 2019 Author Share Posted August 29, 2019 Thanks all and thanks Gerry. Link to comment Share on other sites More sharing options...
Gerry Posted August 29, 2019 Share Posted August 29, 2019 @Markm Did you find a solution? Gerry Link to comment Share on other sites More sharing options...
Markm Posted August 30, 2019 Author Share Posted August 30, 2019 Hi, So after testing all days yesterday it appears that my ADFS works intermittently. I log in with the same user on the same session. It really is 70/30 that it works. There are two ADFS in a pair on WS2012. I've tried URL which directly references one of the ADFS but still he same hit or miss. When i do get the error it looks like below. I cannot honestly work out why it works one moment and not the next. Crazy. Link to comment Share on other sites More sharing options...
Martyn Houghton Posted August 30, 2019 Share Posted August 30, 2019 @Markm When we implemented initially we had some intermittent issues which where down to time synchronisation. You could try adjusting the setting below in to see if the source of the issue in your case is the same. Least that way you can rule it out. Cheers Martyn Link to comment Share on other sites More sharing options...
Gerry Posted August 30, 2019 Share Posted August 30, 2019 @Markm As @Martyn Houghton suggests, its very important that your ADFS/Identity servers are properly time-synced with something thats accurate within a couple of seconds, if you dont do this then all sorts of edge cases can come up. The error message you have posted above is coming from your servers, not ours and to be honest I have no clue what it means, but it is suggesting to contact your sys admin, I expect that the Activity ID in that message is pointing at a system log or log file that will have more details, you would need to find that to determine what the server thinks is wrong. Gerry Link to comment Share on other sites More sharing options...
Markm Posted September 2, 2019 Author Share Posted September 2, 2019 Gents, many thanks for this. The times look similar on both DC and Hornbill server. Ive raised ecurity.saml.timeSkewCompensation to 120secs and also turned it off completed in SSO. Still got the failure but should i really give it 10-15 minutes for the settings to take effect? Link to comment Share on other sites More sharing options...
Markm Posted September 3, 2019 Author Share Posted September 3, 2019 Hi, i have checked again this morning and still getting error with Validate Time disabled. Therefore sadly looks like that isnt my issue. Link to comment Share on other sites More sharing options...
Gerry Posted September 3, 2019 Share Posted September 3, 2019 @Markm I think the suggestion of the time being out of sync was a possible solution, the error you are getting (shown above) is emanating from your identity provider. I had previously suggested you take a look in your ADFS system logs and look for the above shown Activity ID, it should give you more of a hint as to what the problem is. We have 100's of customers using ADFS for SSO and have not seen this problem at all. When you request access to a resource on Hornbill (step 1), if you have no session, Hornbill responds to your browser (step 2) telling the browser to re-direct you to your IDP (ADFS server) (step 3), your iDP will then Authenticate you, and if you are authenticated, your ADFS will (step 4) redirect your browser back to your Hornbill Instance carrying a payload known as an "assertion" which is a digitally signed (by your ADFS) message, the browser (step 3) will then pass this message onto our instance, where we inspect it, verify its digital signature and create you a user session. The message you are showing above looks to me like a page that your ADFS server is returning at Step 4 of the SSO process, so what you need to do is establish what that error message means, we have no visibility of it in our logs as its generated by your ADFS server and displayed in your browser. [edit] the above image and a full description of SAML and how it works can be found here on wikipedia: https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language Does that make sense? Gerry Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now