I am trying to check for revocation of my certificate. I have CAcert certificate.
It takes around 1hour for crlClient and also for OCSP to complete revocation checking of certificate.
Related
RFC 5280 states:
CRL issuers issue CRLs. The CRL issuer is either the CA or an entity that has been authorized by the CA to issue CRLs. CAs publish CRLs to provide status information about the certificates they issued. However, a CA may delegate this responsibility to another trusted authority.
Q: Is there a standard way for a CA to "authorize" a particular CRL issuer that is not the actual CA?
In other words, if a CA certificate contains a CRL Distribution Point URL that contains a CRL that is signed by some key other than the SubjectKey of "this" cert (the one containing the CRL Distribution Point extension), how does "this" CA indicate the valid keys that can sign that CRL?
The CDP entry will contain a cRLIssuer value to indicate what the expected signer of the CRL at that location is.
Then the CRL had to assert that it is an indirectCRL via the Issuing Distribution Point extension.
If the CRL signer is subject is not the same as the issuing CA subject then both Windows and OpenSSL will stop at this point and pretend the CRL doesn’t exist (per https://security.stackexchange.com/questions/242185/deployment-tips-to-support-indirect-crls). But they do, per that question and answer, support the concept to let the CA use a different key for the CA and the CRL signing.
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.
Is revoking an expired certificate a good approach?
An expired certificate is considered an invalid certificate, but it is possible to revoke it. Since it is possible to revoke it, it should be a valid approach by the CA.
Doesn't the CA consider if it is revoked or not and how would it affect the way the certificate is used.
It is a bad idea. No CA do this
An expired certificate will be rejected in general. A digital-signature signature will be verified as invalid using an expired certificate. Browsers reject SSL connections to sites with expired certificates. There is no need of any additional validation
In fact, you will cause an inconsistency with existent signatures. To preserve signatures along certificate expiration time, they are protected with a timestamp. When the certificate of the timestamp is close to expire, an additional timestamp can be issued. Long term signature format AdES also embed the revocation evidences of used certificates.
Revoking an expired certificate means those signatures are valid, but the status of the certificate at CA would be not valid. It has no sense.
From the point of view of the CA, It is a waste of resources. Think in a 20 years old CA with millions of expired certificates in revoked state. It will need an incredible large CRL file( revocation list) to serve and OCSP Services ( online check status) to maintain
Clients are expected to reject expired certificates. If a client, for whatever reason, accepts an expired certificate, and then checks to see if the certificate has been explicitly revoked, it will most likely be disappointed. From RFC 5280 ("Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"):
A complete CRL lists all unexpired certificates, within its scope,
that have been revoked for one of the revocation reasons covered by
the CRL scope. A full and complete CRL lists all unexpired
certificates issued by a CA that have been revoked for any reason.
That is, the CRL will not list any expired certificates.
The InCommon/Comodo CA will not allow you to revoke an already-expired certificate; I suspect that other CA's are set up similarly.
By default, CRLs do not contain information about revoked expired
certificates. The server can include revoked expired certificates by
enabling that option for the issuing point. If expired certificates
are included, information about revoked certificates is not removed
from the CRL when the certificate expires. If expired certificates are
not included, information about revoked certificates is removed from
the CRL when the certificate expires.
source:
https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.0/html/Admin_Guide/Revocation_and_CRLs.html
Is the AuthorityInfoAccess field mandatory in x509v3? I have some certificates, and I'm trying to do OCSP verification, but they don't seem to have this field when I do
openssl x509 -in file.cer -inform DER -text -noout
I was wondering if it's not in that output does that mean it's not there?
Neither extension is mandatory. All they are technically optional. But some applications may require the presence of particular extensions.
For example, for CA certificate it is required to have a Basic Constraints and KeyUsage extensions. Otherwise, the certificate would not be recognized as CA certificate.
In addition, when creating X.509v3 certificates, it is a good practice to include Subject Key Identifier to simplify certificate binding in the chain by using key match.
There are two cases when Authority Information Access (and CRL Distribution Points) should not be presented: in any self-signed certificates and OCSP signing certificates.
As you are talking about OCSP certificate, there is no practical need in this extension, because all required information is elsewhere. For example, if target certificate and its OCSP response are signed by the same CA, existing target certificate's chain is reused. If OCSP uses delegated OCSP signing certificate, then delegated certificate's chain is included in the OCSP response directly.
In practice, badly generated certificates doesn't contain Authority Information Access extension as well.
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.