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
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.
Let's say we have a server only running REST API services, only on HTTPS.
The only consumer of the APIs is a mobile app.
Do we need certificate from CA or a self signed certificate is enough?
You will need to use a CA certificate. Otherwise, each mobile client will have to manually set your certificate as trusted.
You can potentially embed the certificate as trusted in the mobile app itself (assuming you distribute the app), however it will be a problem when the time comes to renew the certificate, or rekey/replace the certificate for whatever issue.
Using a globally trusted certificate is the way to go.
You can :
Keep a self-signed certificate, but then you have to pin the certificate, and you can't revoke it if the private key is compromised.
Use a home made certificate authorities, but then you have to pin the certificate, and manage the revocation process (maintain an OCSP or CRL).
Use a certificate from a trusted CA, revocation will be checked for you, and if you want additional security, you still can pin the certificate.
In my opinion, the use of a trusted CA is more secure and more simple.
I have an architecture where there is a single root CA and multiple sub-CA's. Each sub-CA publishes certificates for devices in it's "domain". Within each domain is a VPN gateway (Cisco router). I would like to determine if it is possible to devise a configuration where each domain's VPN gateway would be able to check to see if the connecting device's certificate has been revoked at it's domain's sub-CA or another of the other domain's sub-CAs. I'm also looking for the most efficient solution which would require as little configuration as possible when adding new domains.
Thanks!
A CRL or OCSP response has the serial number of the revoked certificate in a list, which is signed by the issuing CA or OCSP responder. This ensures that when I revoke certificate serial no 123456789 on my CA that the certificate with the same serial number but issued by your CA isn't revoked instead. Certificate serial numbers, although long, aren't globally unique.
From a security perspective, the ability to revoke another CA's certificates would just cause mayhem and the consequences would be dire.
The only CA that can revoke a certificate is the one that issued it.
I've visited http://msdn.microsoft.com/en-us/library/ff369721.aspx and it is strongly implied that if you need to renew your code signing certificate, then you will need to re-sign your application and re-publish it. There is no change that happens to the certificate from the side of the CA that extends the lifetime of the certificate. Is this correct?
There is no change that happens to the certificate from the side of the CA that
extends the lifetime of the certificate. Is this correct?
No.
The validity dates are included in the certificate, so a certificate with a new expiration date is different than your currently expiring one.