let's say I have Root CA -> Sub CA 1 -> Sub CA 2 -> leaf certificate. I need to check revocation status of leaf certificate by getting all CRLs that provided by Sub CA 2. If leaf cert is in CRL, means that it's no longer valid. Everything is still fine, but how about if Sub CA 2 expired itself or get revoked by Sub CA 1 (maybe even Sub CA 1 expired itself or is revoked by Root CA)? Do CRLs from Sub CA 2 still valid? Do I need to check revocation status recursively from the leaf to the root certificate?
Yes, you have to validate every certificate against issuer CRL, except root certificate. Root certificate is not checked for revocation.
But you don't need to do this (write code) yourself. You should delegate this task to cryptographic libraries that implement certificate validation logic.
Related
I'd like to build my own self-signed CA structure to use in my applications. The idea is presented by the following picture:
So, to summarize it, I want a CA that has several levels of intermediate certificates.
For instance I want to create a Root CA that signs all of my apps and then create an intermediate cert for my first app APP_1. This app is used by several companies so I want that every company has it's own intermediate cert just for them which is signed by APP_1 (you can imagine this intermediate cert as a "child" of APP_1 cert). Company intermediate cert then signs end-user's certificate which he uses on his device.
Is it possible to create this cert hierarchy scheme with OpenSSL?
I've tried to create an example of this scheme and it went well until I tried to verify Company_1 intermediate cert. The verification with the chain was successful, but the verification with the intermediate cert that created this one failed. The command that fails is this one:
openssl verify -CAfile /CA/app_1/certs/app_1.cert.pem /CA/app_1/company_1/certs/company_1.cert.pem
The error is as it follows:
error 2 at 1 depth lookup: unable to get issuer certificate
error /CA/app_1/company_1/certs/company_1.cert.pem: verification failed
What am I doing wrong? Should I also verify the Company_1 intermediate with Root CA as I do with APP_1?
openssl verify by default wants to build the full chain. But you only provide the leaf certificate and the chain certificate and not the root certificate (which is signed by itself). To accept a chain certificate as the final trust anchor instead of a root certificate use the -partial_chain option:
$ openssl verify -partial_chain -CAfile app_1.cert.pem company_1.cert.pem
In accordance with Microsoft a minimum key length for a certificate should be of 1024 bits since August 2012. I have created a self-signed certificate having a key length of 4096 bits. But the certificate information shows the following error:
When I inspected the public key length it shows the following screen:
But instead of having "This certificate is OK." as a status, I am getting the following error:
How can I resolve this issue?
Thanks...
Where do you see a self-signed certificate? Self-signed certificate is the certificate where Subject and Issuer fields are the same. In your case, it is not self-signed.
I can suspect, that the certificate was either, not signed by InfoValley Inc., or signature algorithm is not recognized on your system. Can you tell us the following information:
Authority Key Identifier extension value from leaf certificate
Signature algorithm used to sign leaf certificate (2nd and 3rd fields)
Subject Key Identifier extension value from InfoValley Inc. certificate
I'll explain at least one other way that you can get an invalid digital signature that happened to me. I have a set of scripts that build may certificates and a set of scripts that installs certificates in the windows certificate store. The script that installs the certificates first deletes the certificates that I'm going to install and then installs the new certificates. I thought the script was working just fine, but it turns out I had little bug in the script. I have one Trusted Root CA certificate that is used to sign my Intermediary Trusted Root CA certificates. The problem was that I chose the wrong "certificatestorename" for the trusted root certificate. So, instead actually deleting my trusted root certificate before I installed it, I ended up creating a second trusted root ca certificate in the Trusted Root Certificate Authorities store with the same distinguished name. And that's what cause my 2nd level intermediary CA certificates to report that they had an invalid digital signature.
What made this problem a little difficult to spot was that if I looked at installed 2nd level intermediary CA certificates after being install in the windows certificate store, those 2nd level intermediary CA certificates all showed that the "This certificate is "OK" and no issues with the certificate chain. The problem caused by the two trusted root certificates with the same distinguished name didn't exhibit any problems until I tried to validate a certificate that was signed by one of my 2nd level intermediary CA certificates. It's when I look at those certificates that I saw my 2nd level intermediary CA certificates all had an invalid digital signature.
So, this is at least one way that I observed that you can get this error message. Technically speaking, the error means that the issuer of the certificate cannot validate the signature of the given certificate, which is not the same thing as not finding the issuer certificate in the trusted store. Others have reported that this problem can occur in windows if you generate a certificate whose key length is 512.
Suppose a PKI hierarchy like below.
root CA ==> inter-1 CA ==> user-1
\
\======> inter-2 CA ==> user-2
My question is: does root CA also need to periodically download CRL from its children: inter-1 and inter-2?
Since user-1 and user-2 can authenticate each other, if user-2's certificate is revoked by inter-2, inter-2 should let root know and then propagate to inter-1 and user-1, right?
If so, it seems quite complicated. Is there any tool to use for managing the revocation logic? Thanks a lot.
No, revocation of certificate is not propagated across the CA tree. Each CA (root and intermediate in your case) is responsible of the publication of the CRL containing the list of only the revoked certificates that were issued by this CA.
An example:
Root CA publishes a CRL for the certificates issued by Root CA: inter-1 CA and inter-2 CA. Root CA is not aware of the user-1 and user-2 certificates or their revocation status.
inter-1 CA (resp inter-2 CA) publishes a CRL containing the list of revoked certificates issued by inter-1 CA (resp inter-2 CA) and only these certificates.
CRL Root CA CRL inter-1 CA
^ ^
| |
root CA ==> inter-1 CA ==> user-1
|
| CRL inter-2 CA
| ^
\ |
\======> inter-2 CA ==> user-2
if user-1 certificate is revoked, this certificate (actually its serial number) will only appear in the CRL published by inter-1 CA.
When someone wants to check the validity the user-1 certificate the process is as follows:
build the certificate chain between the certificate and a trusted CA: user-1 / inter-1 CA / root CA
fetch the CRL for the first certificate in the list
verify the signature of the CRL
check the status of the first certificate in the list against this CRL
if the status is not revoked, remove the certificate from the list and go to 2. otherwise fail
if the list contains only the trusted CA, check the chain of signature of the certificates (a certificate must be signed by the following certificate in the list)
if all signature have been checked and are valid, the user-1 certificate is valid.
Note that validating the CRL signature can trigger a validation of another certificate chain : i.e. this algorithm can be recursive. Actually the X.509 certificate validation algorithm is (very) complex and I just summarize the principles here.
I am new to Cryptogrphy, HTTPS and SSL !!!
If i am not wrong , the private key of an End Entity certificate (certificate issued by trusted CA like Verisign) is used to decrypt the information sent by the client !
But does a root certificate also have a Private Key?
If Yes, then I wanted to know where exactly the private key of a root certificate is used?
What happens if it is leaked ?
If I am not wrong, the private key of an End Entity certificate (certificate issued by trusted CA like Verisign) is used to decrypt the information sent by the client
You are wrong. It isn't. The peer's own private key is used to sign the certificate so the client can verify that the peer owns the certificate he presents, and the private key of signing certificates is used to, err, sign certificates.
The root certificate's private key is (normally) only used to sign the intermediate certificates. Compromising it allows you to create new intermediate certificates, and by extension, certificates for any domain.
A root certificate is the top-most certificate of the tree, the private key of which is used to "sign" other certificates. All certificates immediately below the root certificate inherit the trustworthiness of the root certificate - a signature by a root certificate is somewhat analogous to "notarizing" an identity in the physical world. If you knew the private key, you could create new (counterfeit) certificates.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I'm not clear on the difference between a CA key and a certificate. Isn't a CA key simply a certificate? Let me try and clarify with an example.
I have a client and a server. I'm only trying to validate my connection to my server and not trying to establish trust to others so I don't care about signing with a real CA.
Option 1: Generate a self-signed CA (ssCA) and use that to sign a certificate (C). I then install ssCA into the root keystore on my client and setup my server to use certificate C.
Option 2: Generate a self-signed certificate (SSC). Install SSC into the root keystore on my client. Setup my server to use certificate SSC.
The second option seems like a much simpler process. Should that still work?
First, about the distinction between key and certificate (regarding "CA key"), there are 3 pieces used when talking about public-key certificates (typically X.509): the public key, the private key and the certificate.
The public key and the private key form a pair. You can sign and decrypt with the private key, you can verify (a signature) and encrypt with the public key. The public key is intended to be distributed, whereas the private key is meant to be kept private.
A public-key certificate is the combination between a public key and various pieces of information (mostly regarding the identity of the owner of the key pair, whoever controls the private key), this combination being signed using the private key of the issuer of the certificate.
An X.509 certificate has a subject distinguished name and an issuer distinguished name. The issuer name is the subject name of the certificate of the entity issuing the certificate. Self-signed certificates are a special case where the issuer and the subject are the same.
By signing the content of a certificate (i.e. issuing the certificate), the issuer asserts its content, in particular, the binding between the key, the identity (the subject) and the various attributes (which may indicate intent or scope of usage for the certificate).
On top of this, the PKIX specification defines an extension (part of a given certificate) which indicates whether a certificate may be used as a CA certificate, that is, whether it can be used as an issuer for another certificate.
From this, you build a chain of certificates between the end-entity certificate (which is the one you want to verify, for a user or a server) and a CA certificate you trust. There may be intermediate CA certificates (issued by other CA certificates) between the end-entity certificate of your service and the CA certificate you trust. You don't strictly need a root CA at the top (a self-signed CA certificate), but it's often the case (you may choose to trust an intermediate CA certificate directly if you wish).
For your use case, if you generate a self-signed certificate for a specific service, whether it has the CA flag (basic constraints extension) doesn't really matter. You would need it to be a CA certificate to be able to issue other certificates (if you want to build your own PKI). If the certificate you generate for this service is a CA certificate, it shouldn't do any harm. What matters more is the way you can configure your client to trust that certificate for this particular server (browsers should let you make an explicit exception quite easily for example). If the configuration mechanism follows a PKI model (without using specific exceptions), since there won't be a need to build a chain (with just one certificate), you should be able to import the certificate directly as part of the trust anchors of your client, whether it's a CA certificate or not (but this may depend on the configuration mechanism of the client).
Both options are valid, option 2 is simpler.
Option 1 (setting up your own CA) is preferable when you need multiple certificates. In a company you might set up your own CA and install that CA's certificate in the root keystore of all clients. Those clients will then accept all certificates signed by your CA.
Option 2 (self-signing a certificate without a CA) is easier. If you just need a single certificate, then this is sufficient. Install it in the keystores of your clients and you are done. But when you need a second certificate, you need to install that again on all clients.
Here is a link with further information: Creating Certificate Authorities and self-signed SSL certificates
You can openssl x509 -noout -text -in $YOUR_CERT to see the differences between files contents:
In your self-signed CA, you can seeļ¼
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE, pathlen:0
And in your self-signed certificate, it's:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
If you need more certificates (C), you need to create a self-signed CA (ssCA).
If you need a single certificate, you can just create a self-signed certificate (SSC).
To trust the single certificate (SSC), you need to install SSC into the root keystore on your client.
To trust many certificates at once, you need to create a self-signed CA (ssCA), then install ssCA into the root keystore on your client.
You must always have a root CA, the CA has a key that can be used to sign a lower level certificate and a root certificate that can be embedded in the accepted root certificates on the client and is used to verify the lower certificates to check they are valid. Self signed just means you are your own CA. Whenever creating a self signed certificate you create a ca, then sign a site cert with that CA.