Certificate Error

[derekgreen]

Help! Numerous users are reporting the attached error when attempting to log in to the Service Portal. Any ideas?

[Martyn Houghton]

@derekgreen

Your single sign on trust certificate has expired. You need to login with the bypass option into the admin took and then reenter the URL to import the certificate from your SSO source system.

I dig out the bypass option option URL and add it too this post shortly.

Cheers

Martyn

[TrevorKillick]

A recent Post from Gerry details how to update your Single Sign On Configuration to contain the updated Certificate from your ADF Servers.
 

Kind Regards

Trevor Killick

[Martyn Houghton]

@derekgreen

You can log in with your non SSO admin user that would have been setup and provided as part of the Hornbill Switch On process using the url below, replacing your instance name.

https://admin.hornbill.com/<instance_name>/?ESPBasic=true

Then you can follow the steps as Trevor has linked to.

Cheers

Martyn

 

[derekgreen]

Thanks guys. All of our ADFS configuration was done by a third party. How do I actually identify and update the certificate? I have attached a snip of the certificate(s) as presented in our SSO config.

[Martyn Houghton]

@derekgreen

Hopefully you have the endpoint URL of your ADFS server which you can use to import an updated certificate from. Our is along the lines of https://......../federationmetadata/2007-06/federationmetadata.xml but would be specific to your provider. Once you have this you can click on the button in the top right hand corner to  to enter the endpoint an re-import an updated trust certificate in the dialog window that appears.

 

As as workaround to get live app users in you could temporarily disable the SSO config and then choose to create passwords from the admin tool for your key users, whilst you sort out the SSO config.

Cheers

Martyn

 

[Victor]

@derekgreen as @Martyn Houghton suggested you need either teh URL or the SAML metadata file (the XML file). You need to ask the ADSF guy to give you this. They know what it is. Until you get this you can temporarily disable certificate validation to allow your users to log in.

EDIT: @Martyn Houghton disabling SSO allogether is indeed an option, but if you have hundreds of basic users.. well.. it might take a while to reset all passwords

[Martyn Houghton]

@Victor

Indeed disabling SSO is not the easy route, but is something we have in our Business Continuity plan if we lose our ADFS servers. Fingers crossed I never have to do it 

Cheers

Martyn

[derekgreen]

Not having much joy here I'm afraid. I have identified the url to the metadata xml but when I process it I get a message back saying empty xml.

[Victor]

@derekgreen send me the XML in a PM please

[derekgreen]

Hi Victor - I'd love to if only I could find it!

[derekgreen]

Victor - would you be able to remotely access our ADFS server? 

[Victor]

@derekgreen I'm afraid can't... I simply don't know the product (ADFS)  ... I can work with the XML file (or information) provided by the IdP (in this case ADFS) but to go in and look for it in the IdP itself I do not know

[TrevorKillick]

@derekgreen

The XML URL is typically something like this:

https://adfs.yourdomain.com/FederationMetadata/2007-06/FederationMetadata.xml

The exact subdomain should be in the entity Id against your SSO profile.

Kind Regards

Trevor Killick

[nasimg]

If you have revert to the username/password option (not SSO), you don't need to reset the password individually. Tell your customers to use the forgot password option to reset it themselves.

Regards

Nasim

[dconagh]

Hello,

Was this ever resolved as I am experiencing the exact same problem.

Thank you,

Dan

[Victor]

@dconagh oops... looks like we missed your reply, apologies Do you still experience the problem?