I had trouble confirming this online- Are the OCSP server URLs specified in the X509 certificate of the CA, like CRLs, or must they specified out of band by the network administrator? How does the verifier know which OCSP server to use to verify a given certificate (assuming we have its certificate path)?
The Authority Information Access (AIA) details in an X.509 certificate will describe the location of the OCSP server.
The certificate authority that issued the certificate will had added the OCSP information to the certificate issued to the entity. The requester of the certificate has no choice over this and thus cannot hide the presence of the OCSP server.
OCSP clients can parse the certificate, note the presence of an OCSP AIA entry and make the validation request.
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 wonder if anyone can provide more detailed description of point 2 of the answer to How are ssl certificates verified?.
What algorithms are used to verify that the certificate was signed by the trusted CA? What ideas are they based on? Why it is not possible to simulate trusted CA signature (make a certificate that the browser will treat as valid)?
It's a digital signature. You can verify it via the public key in the associated certificate. The algorithms are as specified in the certificate itself.
As far as I know and as it is mentioned here there are two main technologies for browsers to check the revocation status of a particular certificate: using the Online Certificate Status Protocol (OCSP) or looking up the certificate in a Certificate Revocation List (CRL).
Well, I know that there is some online OCSP servers or the OCSP method and the browser send a request there to check if the incoming certificate is revoked, but I don't have any idea about the CRL.
Where is the CRL? Is it a file in my system that updated after OCSP requests or it is a list in the web server that I'm trying to connect to?
Who updates it?
How do OCSP server check revocation? (I mean how does it update its database of revoked certificates?)
Note that I know I can see a cache of CRL using certutil -urlcache crl in command line. But it is a cache of it! Where is the real file?
Where is CRL? Is it a file in my system that updated after OCSP requests or it is a list in the web server that I'm trying to connect to?
CRL is a list provided by the certificate issuer. The list contains the serial numbers and the reason for revocation of the revoked certificates and is signed by the issuer (or some other directly or indirectly trusted CA). The original CRL file is created and stored at the issuer. It gets provided usually via http/https but other mechanism exists. To know which URL provides the CRL for a specific certificate look at the 'CRL Distribution Points' property of the certificate. Note that lots of certificates issued by the same CA share the same CRL distribution point.
Where the local copy of the CRL is on your system, in which format it is stored there etc depends on the OS, browser, libraries... I doubt that it will be updated based on OCSP responses because OCSP and CRL are independent mechanism to check for revocation and a client usually only uses one of these to check for revocation of specific certificates. But it might use OCSP in some cases and CRL in other cases (where no OCSP is provided).
Who it updates?
It depends. Browsers usually don't use CRL's anymore but moved to OCSP, skip revocation checks completely or moved to some other mechanism like CRLSets. If any other application use CRL for the certificates - it probably depends on the application.
How OCSP server check revocation? (I mean how it update its database of revoked certificates?)
It does not check for revocation. Either the OCSP server is provided by the certificate issuer itself which already has the list of revoked certificates (since the issuer revoked these itself) or in case of OCSP stapling the web server gets the (signed) OCSP response from the issuer and includes it unchanged inside the TLS handshake.
In theory one could build some OCSP proxy which provides OCSP responses based on existing CRL files but since the OCSP responses are signed too this proxy must have a certificate which is explicitly trusted for signing OCSP responses.
As far as I know, the web browser use OCSP packets to check if the incoming certificate (from a web server) is still valid or it is revoked.
I have some questions about it:
1- Am I Right about the OCSP?
2- Does the browser send a OCSP request for every incoming cert?
3- Where is the destication of these requests? Root CA?
Well, I monitor the data transmission on my network adapter using Wireshark and I catch the following request :
click to enlarge
[]1
Well, above observation added 3 more question to above questions:
4- I did a whois IP the destination IP and the result shows that it is a23-51-123-27.deploy.static.akamaitechnologies.com . Is it really a Root CA?
5- This request is sent in plain and is not encrypted with SSL protocol! Why? Can't it simply attacked with MITM attacks?
6- This packet contains issuerNameHash, issuerKeyHash and serialNumber only! Are they enough really?! Why hashed values sent?
That's a lot of questions to answer.
Web browser will check OCSP responder for certificate revocation information only if it is set (to do so) in the browser settings and only if there is URL to OCSP in the certificate to validate.
First a certificate chain is built. Each certificate in the chain (excluding root which is trusted in your certificate store, or not :) ) will be validated by OCSP (if conditions in "1" are met).
It's not RootCA for every certificate. Each certificate in chain could contain url to OCSP server. OCSP server certificate has to be issued by the CA that it is working for so each CA will have (could have, it is not a mandatory service) its dedicated OCSP server. OCSP request will go to the corresponding OCSP server based on the url from certificate being validated.
I don't know what that url is. But there is a OCSP server running at IP 23.51.123.27 according to the dump.
Because that is the way OCSP works :). There are only public information in the request so nothing that would require encryption. Response is signed by OCSP server issued by the same CA that issued validated certificate. Client can easily validate that the response was not tampered with (signature chech) and that it was issued by valid OCSP responder - again nothing to encrypt. Read RFC 6960 for more information.
Yes, it is enough information. Certificate is identified by serial number and issuer. OCSP responder provides service for the CA that issued its certificate so OCSP server can validate that the request is valid (same issuer). OCSP server can (but is is only an extension to OCSP protocol and not widely used AFAIK) send back thumbprint of the validated certificate. It is a confirmation that OCSP server knows about the certificate.
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.