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.
Related
I have 2 Private CAs at the moment, one Root CA and a Subordinate CA. The Subordinate CA's CSR is signed by the Root CA. We have apps that would be using the Subordinate CA to do mutual TLS authentication.
Question: I have existing certificates that have been signed by the Root CA, can that be used in conjunction with the Subordinate CA? Or do I have to create new certificates that are signed by the Subordinate CA in order for it to work?
The certificates signed by the root CA are trusted. It is the nature of PKI. If you place RootCA's certificated into CA store, then all certificates signed by that certifcate will be valid. Still ...
Typically it is considered unwise to sign end-users certificates with the root. It is a long-lasting certificate that serves as the cornerstone of the whole infrastructure. In your place I would consider unifying PKI and re-issue the end-users' and servers' certificates using the intermediate CA.
When I use self-sign certificate, I made a self-CA.cer and a server.cer, server.cer is for web service and self-CA.cer is added in client code. When I check certificate , I check if server.cer is from this self-CA.cer, right?
But, if I buy a CA certificate, what I only got is a server.cer generated from CA, right? and CA certificate can generate many server.cer, and they are all trusted , what I got is one from these .
In my client code, others said I only need to change my http to https, that's it ,after I buy CA. but how can I distinguish which server certificate is from my own server? I only want trust the server certificate from my own server.
if I buy a CA certificate
you can't buy a CA certificate (with small exception, which is not your case). You are purchasing an end-entity certificate which cannot be used to sign other certificates. It is controlled by a Basic Constraints certificate. Any standard validation code will reject any certificate that is signed by non-CA certificate due to Basic Constraints extension value (isCA attribute is set to False).
RFC 5280 -- Basic Constraints
If you trust a CA you trust all certs they issue (unless expired or revoked) -- that's how PKI works.
If that CA issues certs to other sites/servers, and you make HTTPS (or otherwise SSL/TLS or DTLS) connections to those other sites/severs, you will trust their certs and thus trust them.
But if you mean you want to trust only the specific cert issued to your server for your server, that's automatic. The cert issued to your server has your domain name in it, while the certs issued to other servers have their (different) names, and an HTTPS client like a browser will only trust a cert that is issued by a trusted CA and has the correct server name in it, so it will trust only your cert for your server, and will trust other certs only for the other servers those certs are issued to.
For much more detail, see Stack's Great Ursine Epic https://security.stackexchange.com/questions/20803/how-does-ssl-work/
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.
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."