Hi I have multiple IDPs registered under our ADFS Claims Trust Provider. One of the IDP's federation metadata has expired certificate. Corresponding party has successful integration (with expired certificate) with other 3rd party Service Provider (non MS platform). So basically I was told to integrate this IDP with expired certificate under our ADFS SP.
Now every time when User from this IDP logs in and try to get redirected via ADFS we get following error in event log.
An error occurred during an attempt to build the certificate chain for the claims provider trust 'https://xyz.com/opensso' certificate identified by thumbprint 'D13412341231312312311231313123'.
Possible causes are that the certificate has been revoked, the certificate chain could not be verified as specified by the claims provider trust's signing certificate revocation settings or certificate is not within its validity period.
You can use Windows PowerShell commands for AD FS to configure the revocation settings for the claims provider trust's signing certificate.
Claims provider trust's signing certificate revocation settings: None
The following errors occurred while building the certificate chain:
MSIS2013: A required certificate is not within its validity period when verifying against the current system clock.
User Action:
Ensure that the claims provider trust's signing certificate is valid and has not been revoked.
Ensure that AD FS can access the certificate revocation list if the revocation setting does not specify "none" or a "cache only" setting.
Verify your proxy server setting. For more information about how to verify your proxy server setting, see the AD FS Troubleshooting Guide (http://go.microsoft.com/fwlink/?LinkId=182180).
I already tried following cmdlets but no success so far.
Set-ADFSClaimsProviderTrust -TargetName "ABC Test" -SigningCertificateRevocationCheck "None"
Set-ADFSClaimsProviderTrust -TargetName "ABC Test" -EncryptionCertificateRevocationCheck "None"
We are using ADFS 3.0 in farm setup. Is it really possible to use Claims Identity Provider with expired certificate?
Thanks
No - it's not.
All based on trust and if the certificate has expired so has the trust.
The commands that you are running are simply telling ADFS not to verify the validity of the certificate in terms of the CA signing authority.
There is no command to unexpire a certificate - you need to get a new, valid one.
And that's the way it should it should be from a security PoV.
Related
I am receiving an exception on ADFS while integrating private.xyz.com. The exception says.
Microsoft.IdentityServer.Service.SecurityTokenService.RevocationValidationException: MSIS3015: The signing certificate of the claims provider trust 'https://private.xyz.com/sp' identified by thumbprint '****************************' is not valid. It might indicate that the certificate has been revoked, has expired, or that the certificate chain is not trusted.
at Microsoft.IdentityServer.Service.Tokens.MSISX509SecurityToken.MatchesKeyIdentifierClause(SecurityKeyIdentifierClause keyIdentifierClause)
at System.IdentityModel.Tokens.SecurityToken.ResolveKeyIdentifierClause(SecurityKeyIdentifierClause keyIdentifierClause)
at
The signing certificate is configured in the relying party trust
Get-AdfsRelyingPartyTrust "private" | fl name,RequestSigningCertificate
The thumbprint which I am getting for the certificate is same what I am getting in the error message. And the certificate is also not expired.
What all do I need to configure so I can resolve this?
If the certificate has not been revoked or is still current, it is usually because ADFS can't locate the certificate revocation list on the Internet. You can turn this off via PS.
Also, it could be that the intermediate certificates aren't loaded into the certificate store or that the certificate itself is not trusted.
You could manually add it to Trusted Certificates.
Background:
1. Originally SAML based on the ADFS works fine, but after the ADFS certificate update, it can't work fine. Since the certificate of the ADFS will be expired, so we update the certificate, but unfortunately can not work fine with updated certificate ADFS
The exception is "Signature is not trusted or invalid" which thrown in the spring SAML. Does there exist some especially needed to be noticed when update the ADFS certificate?
You need to regenerate the Identity provider (IDP) XML file i.e federation-metadata.xml and exchange with the client i.e Service provider. As you mentioned that ADFS certificates were expired and you reconfigured the new certificates, so those play a significant role for encryption and signing of assertions issued from the IDP based on how the system is configured. You have made the changes on the IDP side but on SP side still, old federation-metadata.xml is in use with old certificates. When IDP issued assertions or response, that response is validated by using those certificates. When you regenerate that file it will contain the latest details related to certificates. So you need to regenerate the federation-metadata.xml and share with the service provider (SP) in order to fix the issue.
From ADFS and ADFS 2.0 perspective is it possible to register Service Provider metadata that is using certificate (public key) that is not issued by signing authority ? I mean on self signing certificate.
Yes - you can use a self-signed certificate for the SP and that certificate is reflected in the SP metadata.
So you can generate it with the Java keytool etc.
Also ensure that you generate the certificate for a reasonable period - at least a year otherwise you will have to co0ntinually update the metadata on the ADFS side.
It should not be as described in following document -
Certificate Requirements for Federation Servers in section Determining your CA strategy
"ADFS does not require that certificates be issued by a CA. However, the SSL certificate (the certificate that is also used by default as the service communications certificate) must be trusted by the ADFS clients. We recommend that you not use self-signed certificates for these certificate types."
I have the following scenario:
Active Directory 1: WCF Client, ADFS 2.0 (STS)
Active Directory 2: WCF service (Relying Party)
I have added the RP to the ADFS but when I request a token from the ADFS I recieve the following error: System.ServiceModel.FaultException: ID3242: The security token could not be authenticated or authorized.
Looking at the event log of the ADFS I find the matching error:
An error occurred during an attempt to build the certificate chain for
the relying party trust 'http://XXXXX/Service1/' certificate
identified by thumbprint 'XXXXXXXXXXXX'. Possible causes are that the
certificate has been revoked, the certificate chain could not be
verified as specified by the relying party trust's encryption
certificate revocation settings or certificate is not within its
validity period.
You can use Windows PowerShell commands for AD FS 2.0 to configure the
revocation settings for the relying party encryption certificate.
Relying party trust's encryption certificate revocation settings:
CheckChainExcludeRoot The following errors occurred while building
the certificate chain: Unknown error. Unknown error.
User Action: Ensure that the relying party trust's encryption
certificate is valid and has not been revoked. Ensure that AD FS 2.0
can access the certificate revocation list if the revocation setting
does not specify "none" or a "cache only" setting. Verify your proxy
server setting. For more information about how to verify your proxy
server setting, see the AD FS 2.0 Troubleshooting Guide
(http://go.microsoft.com/fwlink/?LinkId=182180).
Looks like the ADFS does not trust the signing certificate from the RP (understandable, the CA which issued the Signing certificate is in a different AD).
The CertificateRevokationList is reachable from both Active Directories.
I have added the CA certificate to the Trusted Root Certificates of the "Local Computer", but I think the problem is the validation mechanism.
What do I have to configure to get the ADFS to issue a token signed with the proper certificate or how can I convince the ADFS that the certificate is valid?
EDIT:
I have tried changing the revokation check with the powershell command:
Set-ADFSRelyingPartyTrust -SigningCertificateRevocationCheck CheckEndCert
but with no luck:
Set-ADFSRelyingPartyTrust : Parameter set cannot be resolved using the specified named parameters.
At line:1 char:26
+ Set-ADFSRelyingPartyTrust <<<< -SigningCertificateRevocationCheck CheckEndCert
+ CategoryInfo : InvalidArgument: (:) [Set-ADFSRelyingPartyTrust], ParameterBindingException
+ FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.IdentityServer.PowerShell.Commands.SetRelyingPartyTrustC
ommand
EDIT 2:
This worked:
(Get-ADFSRelyingPartyTrust) | Set-ADFSRelyingPartyTrust -EncryptionCertificateRevocationCheck CheckEndCert
but now my client in Active Directory 1 complains about the certificate...
System.ServiceModel.Security.SecurityNegotiationException: SOAP
security negotiation with
'http://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/Service1/' for target
'http://XXXXXXXXXXXXXXXXX/Service1/' failed. See inner exception for
more details. --->
System.IdentityModel.Tokens.SecurityTokenValidationException: The
X.509 certificate CN=RP-Service chain building failed. The certificate
that was used has a trust chain that cannot be verified. Replace the
certificate or change the certificateValidationMode. A certificate
chain could not be built to a trusted root authority.
Maybe you should try to add your RP-Service cert into Trusted People store on the machine, where your WCF client runs. That was what I did when using self-signed cert to test WCF call under federation with ADFS.
I'm facing the same error. What helps is using
Set-ADFSRelyingPartyTrust -EncryptionCertificateRevocationCheck None
But this will only disable the check on the RP part. Since we're talking about federation the same will happen on the federated server. So you have to do it there too. Anyways, it only changed the errors i get - i still can't federate ATM.
The command that works for me is this:
Set-ADFSRelyingPartyTrust -TargetName <relyingpartytrustName> -EncryptionCertificateRevocationCheck None
We have several times, resulted to installing the signing and encryption certificates (self-signed certs generated by ADFS) everywhere (i.e. the servers hosting the WCF services).
When I login to my bank account using https, it's only a server side SSL authentication before I enter my login info. My browser does the server authentication based on the certificate info from the server during SSL session. I did not have to do any manual import of server certificate as a trusted cert into my browser. It just happens at runtime during SSL exchange.
On the other hand, I have also seen applications where one has to manually import the certificate (using keytool for e.g.) when you look into their install guide.
Question is: If the certificate info is exchanged in the beginning of SSL session, each side has enough info to authenticate the other side. Why would some apps require manual import of certs from each other between client and server. Be it either or both side authentication.
ADDITIONAL INFO based on the responses below:
I was referring the scenario where I was installing a commercial software based on client-server model with client side SSL authentication turned ON. I installed the server on machine A and 2 clients on different machines all in my private network. During install, server generates a self-signed certificate locally. So do the 2 clients. Once installation is complete, I was asked to copy the clients' certs to server machine and manually import them as trusted certs. Also, copy the server cert to client machines and do the import into their trusted store. They provided a wrapper tool on top of java keytool to perform the cert import. Why is this manual import necessary here? The client and server will anyway exchange certificate info during SSL handshake and perform the authentication. Again, these are self-signed certs and CA involved here.
Note that a certificate is signed by a certificate authority so it depends on which certificate authorities your browser trusts. If the Web server sends a certificate signed by a certificate authority that’s trusted by the browser/application and the certificate is valid, you shouldn’t get any warnings whatsoever.
On the other hand, if the browser receives a certificate from the Web server and it doesn’t trust the certificate authority that signed that certificate, the browser will take some action — at the very least, it should warn you about this. When you import a certificate from a Web site, you’re essentially telling your browser that you have decided to trust that certificate independently of who signed it.
Edit: The same reasoning applies: The keystore keeps a list of trusted certificate authorities and their corresponding certificates. The whole concept of PKI is to have a hierarchy of trusted CAs that emit signed certificates for other parties. If a certificate is self-signed, there’s no valid trust chain — how will Java know that the certificate hasn’t been forged by an attacker?
You’re assuming that a connection between a client and a Web server is implicitly trusted just because certificates are exchanged during the SSL handshake. What if a man in the middle poses as the Web server and, instead of sending the server certificate, sends his own certificate instead? How would clients know that the certificate received by the man in the middle is not to be trusted? If the certificate is signed by a trusted CA, or if the certificate has been manually added to the keystore as a trusted certificate, the client can check whether it should trust the certificate or not.
An SSL server's certificate has to be "vouched for" by a certificate authority (CA). Your browser (or other program) contains a list of CAs it trusts. If you're using a site that is not certified by one of the standard CAs, then you'd have to import its CA in order for the verification to succeed.
No legitimate site (especially for online banking) should require you to use an "alternative" CA. Only do this for sites where you're not sending super-sensitive data.