Suppose I receive a chain of certificates: [leaf cert, intermediate cert 1, intermediate cert 2, intermediate cert 3...] How do I manually verify that the certificate has not been revoked using OCSP requests? The leaf certificate has OCSP server attached to it.
I have listed the possible options that I have thought of:
issue OCSP request with the CreateOCSPRequest(intermediate cert, leaf cert) for each intermediate cert in the cert chain (ie. CreateOCSPRequest(intermediate cert 3, leaf cert), CreateOCSPRequest(intermediate cert 2, leaf cert), CreateOCSPRequest(intermediate cert 1, leaf cert), etc.)
just one OCSP request with CreateOCSPRequest(intermediate cert 1, leaf cert), not checking the other certs in the chain
issue OCSP request with the CreateOCSPRequest(intermediate cert, leaf cert) for each intermediate cert in the cert chain, except the last cert in the cert chain (which appears to be the approach here: https://sourcegraph.com/github.com/cockroachdb/cockroach/-/blob/pkg/security/ocsp.go?L48)
issue OCSP request with the CreateOCSPRequest(intermediate cert, leaf cert) for each intermediate cert in the cert chain, until we reach a root cert that we can trust
issue OCSP request with CreateOCSPRequest(cert's issuer cert, cert) for each intermediate cert in the cert chain (have the intermediate cert as the cert to check in the OSCP request, instead of the leaf cert, so we issue requests CreateOCSPRequest(intermediate cert 1, leaf cert),CreateOCSPRequest(intermediate cert 2, intermediate cert 1),
CreateOCSPRequest(intermediate cert 3, intermediate cert 2), etc.)
something else
My current implementation is option 1. I don't think my solution (option 1) is the right answer, however, as I get an unauthorized error when I try to issue an OCSP request with (intermediate cert 4, leaf cert) in my test cert chain.
CreateOCSPRequest(issuer, cert) is the placeholder function that creates an OCSP request with the issuer and cert. I'm using the ocsp.CreateRequest in Golang, although I'm sure there are similar functions in other languages.
Related
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs. On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
I know the truststore is to verify the 3rd party certificate during handshake
My question is what should my truststore actually store during handshake?
Youtube.pem (the CA signed certificate sent from 3rd part)
Google.crt (the CA certificate)
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs.
Yes, but you only need a keystore if you want to use client side authentication. Note that "keystore" and "truststore" indicate how the store is used, they can be of the same type (e.g. PKCS#12) and even the same file.
On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
No, YouTube is a service, it has a leaf or end-entity certificate. The root certificate is that of a third party CA. The end-entity certificate is usually signed by an intermediate CA certificate, and that is in turn signed by a self signed root certificate.
I know the truststore is to verify the 3rd party certificate during handshake
It is used to validate and verify the trust path from leaf certificate to a trust anchor in your truststore. The trust anchor is usually one of the root certificates stored in your truststore. The leaf certificate is indicated by the end entity / server, the intermediate certificates are usually sent by the server as well, but they could also be retrieved from a cache.
In the case of YouTube, the Google root CA is used, possibly using the GlobalSign root through a linked certificate if the Google root is not present in the trust store.
So your truststore should either contain the Google root certificate or the GlobalSign root for the connection to work in this example.
I have a .keystore file and Tomcat's configuration is: keystore=.keystore and truststore=.keystore
The .keystore contains a PrivateKeyEntry (signed by CA1) and a trustedCertEntry (CA1).
Everythink ok so far.
If the trustedCertEntry would not be present when importing server certificate, I would get: Failed to establish chain from reply
When I delete the trustedCertEntry (CA1), Tomcat can not start because of: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
Now my question: When I delete trustedCertEntry CA1 and import a trustedCertEntry CA2, Tomcat starts and the certificate chain (view in browser) is: The server certificate which is signed by CA1.
How can this be possible? I would have expected that Tomcat can not start since the trustedCertEntry (CA2) does not match with the PrivateKeyEntry since PrivateKeyEntry was issued from CA1 and not CA2. And since Tomcat can not start without a trustedCertEntry.
Private key is not issued by CA.
Your server certificate is a pair of public and private key. Based on this key pair certificate request was created and this certificate request was signed by CA1. Certificate is valid in your browser as long as CA1 is in trusted CA in certificate store of your browser.
Changing CA in keystore doesn't affect server certificate.
It looks like at least one CA cert is requirement of SSL engine - I'm guessing that any CA cert (i.e. thawte.com/roots, or self-signed) imported to JKS will work for you - JKS must have at least one.
I am using OpenSSL program to generate my SSL self-signed certificate, created a CA certificate and a webserver certificate. The webserver certificate, I have signed it with the CA certificate. I created a keystore with Java's keytool to import webserver's certificate.
On the client side, I have imported the CA certificate inside client's Certificate Manager, under the "Trusted Root Certification Authorities".
In theory, is this way considered as a One way TLS or a Two way TLS communication?
Thank you so much for the help!
In TLS protocol by default the client validates servers authenticity, the server sends its certificate during the handshake and the client validates it with the CA certificate in its trust store. It is one way setup
For two way, during the handshake, the server also asks for certificate from client,it validates the certificate sent by the client with the CA certificate in its trust store. So if you want to use two way setup, you need to generate client CA certificate and client certificate(it will be signed by the client CA certificate), the same CA certificate you need to configure at server so that it(server) will be able to validate the client certificate it received during the handshake.
You can also decide to keep same CA certificate for both client and server certificates, making sure client and server certificates are signed by the same CA
If I buy a cert for mycompany.com and I get a valid cert signed by Verisign, What prevents me from generating a fake certificate that is for othercompany.com signed by mycompany?
Doing a man in the middle attack what prevents me from issuing a fake cert for othercompany.com signed by mycompany and include my valid cert as an intermediate CA cert.
One of the "Basic Constraints" that can be attached to a certificate by the issuer is whether or not the certificate is permitted to sign other certificates. These constraints can't be modified without invalidating the certificate. Since a CA will always issue you with a certificate that is marked as an "End Entity" you won't be able to use it to issue other certificates.
Whilst you could likely still create a certificate issued by an "End Entity", any software that correctly validates a certificate chain will mark such a certificate as invalid and reject it.
Is CA certificate same client certificate?
If not how can I get client certificate? If yes how can I use it as client certificate?
Sorry for the dumb question.
Thanks in advance.
Server cert or client cert are just certs, they only have different properties. Everyone in the certification tree (including the end-users, and certificate issuers) has a certificate, usually X509 Certificate.
The certification authorities are on a tree structure (the depth of the tree is not fixed):
Root certication authority of a country (level 0)
Certification authority 1 (level 1)
Certification authority 1.1 (level 2)
End-user 1.1.1
End-user 1.1.2
...
Certification authority 1.2 (level 2)
...
Certification authority 2 (level 1)
...
The certificate of end-user is signed by the certification authority at the leaf of the tree. And each certification authority also has a certificate which is signed by the parent certification authority.
The certificate of the root certification authority (level 0) is signed by this root CA itself.
Take 1 example: Certification authority A has a child certification authority B, and the certification authority B issues a cert for end-user C.
For this example: the cert that B is holding and the cert that C is holding are different. The B's cert is signed by A, the C's cert is signed by B. And these certs are definitely different also, because the contents of certs are different.
And regarding how to get a certificate, there are 2 ways: (1) find a certification authority and ask them to buy a cert, (2) use certificate generation software to create your own cert. However, the cert issued by a CA has validity by law, the one generated by yourself can't be used to sign anything legally, and thus the cert generated by yourself can be used as a test cert only.
A certificate file (.cer, .p12, etc.) can be imported to browser; for the Chrome Browser: open 'Settings' --> 'Advanced' --> 'HTTPS/SSL' --> 'Manage certificates' --> 'Import'. The file .cer is X509 certificate (no private key), the file .p12 is PKCS12 certificate (containing private key). Not all certificates are trusted by browser; only those certs issued by a CA in a certification tree which has the root CA known by browser are trusted.