For firewall purposes, trying to identify the cert revocation URL's for the major root CA's. Are these documented somewhere?
In addition to Crypt32's answer you should be able to get a CRL from a certificate itself. For instance if you look at the certificate for https://www.google.com (using a browser) you can see a CRL distribution point of http://crl.pki.goog/GTS1O1.crl
The two certificates above it in the chain also have CRLs.
Related
We have configured our Nginx webserver to perform client cert authentication with the ssl_verify_client set to optional_no_ca.
With this optional_no_ca configuration, Nginx shouldn't drop the request if the client cert is issued by a different CA and, Nginx should provide the result of this authentication in ssl_client_verify variable, which we can use to drop or allow the request.
But, we don't observe this behaviour. Nginx drops the request with the below error.
FAILED:unable to verify the first certificate
To give additional context, we have two root CA certificates, some clients are signed with FirstRoot CA and some are signed with SecondRoot CA. (I understand that this is a wrong design)
In Nginx's ssl_client_certificate directive, we have provided the FirstRoot CA file path, and we observe that the client certificates issued by the SecondRoot CA's are getting dropped.
Is my understanding towards the optional_no_ca usage correct? Please provide any ideas to drill this down. Thanks for your time.
I am using a setup wherein a chain certificate(Root CA Cert-> Intermediate CA Cert -> Client Cert) is being sent to the Nginx. I need to configure Nginx in such a way that it forwards the entire certificate chain to the middleware. Right now, it is just sending the leaf certificate i.e. client certificate.
I found the following options from the Nginx's documentation (http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate)
1- $ssl_client_escaped_cert
2- $ssl_client_cert
None of the above returns the full certificate chain.
Is anyone aware if there is such an option available ?
This seems to be impossible by design - see https://serverfault.com/questions/576965/nginx-proxy-pass-with-a-backend-requesting-client-certificates
The usage of $ssl_client_escaped_cert (as explained in https://clairekeum.wordpress.com/2018/12/05/passing-client-cert-through-nginx-to-the-backend/) seems to be your only option.
This may not be a complete answer, but thought I'd post some resources that may give you a couple of ideas.
If you want the client cert details downstream, then one option is to avoid terminating Mutual TLS in nginx by using the stream module. Here is an example:
Mutual TLS Secured API Blog Post .
NGINX Config
In this setup there are 2 Mutual TLS connections being routed via nginx:
To authenticate with an Authorization Server - where Mutual TLS is not handled by nginx
To call an API with a certificate bound access token - where nginx terminates TLS
Note that this uses a LUA plugin and the ssl_client_raw_cert property to do the extra work of calculating a SHA256 thumbprint, which NGINX itself does not support.
Generally though it makes sense to externalise Mutual TLS plumbing from application level components, as in the above example. Eg you can forward ssl_client_eacaped_cert to your middleware, but perhaps nginx should do the more detailed work of checking issuers.
The TLS server is configured to send the leaf and intermediate certificates on TLS handshake.
The TLS client will validate the trust-chain of the server leaf certificate with the help of intermediate and root certificates. The root certificate must exist local on the client, the server leaf certificate must be sent from the server. However if the intermediate certificate exists locally on the client and is sent from the server - in this case there are two copies of the intermediate certificate available to the validation process. Which copy of the intermediate certificate will be chosen to be used to validate the chain of trust?
It depends on specific implementation of certificate chaining engine and is outside of TLS scope. Certificate chaining engine constructs as much chains as it can by using all available information. After building all chains, CCE eliminates duplicate ones, then based on internal algorithm, selects the best chain which is used for further operations.
There might be a case when local intermediate certificate is better than the one received from TLS handshake. In this case, intermediate certificate received from TLS is not used.
I could find any quick answer on google. Most probably the answer lies somewhere in RFC docs on http or https however I just couldn't (too time consuming ) get those information.
So here is the question:
Is the content of a webpage served through HTTP signed digitally by the server ? Same question for HTTPS.
If yes, how does it work correctly when using a proxy ? In my opinion the proxy could tamper the data, sign the tampered data with it's own private key, and claim that the corresponding proxy's public key is actually the genuine public key of the original server ? I am assuming that the client can't check the original server's public key, because there is a proxy which could lie.
I am sorry if this is a dump question and easy searchable on the internet, but every answer I found posed some doubts to me.
Thanks for your help :)
Content sent via HTTPS is encrypted, clients verify the authenticity of the host certificates with whom they are communicating. The server uses a TLS/SSL key/certificate which is signed by certificate authorities (CA) The CAs make sure that they only sign the certificates of the rightful owners of a domain. The certificates of the CAs them-self are installed in you browser/OS. By using these pre-installed certificates, the browser can check if the key used by the remote server is signed by a trusted CA.
A man-in-the-middle does not have the original key, nor another key signed by a CA for the domain in question. Therefore, a man-in-the-middle cannot modify the content without breaking HTTPS.
On the other hand, if you want to use a proxy to cache requests, the proxy can terminate the HTTPS connections. This means the proxy has its own connection to the server and verifies the certificates. In order to secure the connection to the client, the proxy acts as a CA and uses a HTTPS connection with self-signed certificates. To avoid that your browser complains about an insecure connection, you need to install the proxies own CA certificate.
HTTP content is not signed and can be tampered with.
Edit 2018-06-15:
I wasn't really precise with the term "signed" here. The server does not actually sign the content it sends. This means if you store the responses from the server, you cannot prove that they came from that server, in other words: standard TLS dose not provide non-repudiation. However, the authenticity of the server is established during the handshake. The client encrypts a master-key with the servers public key. Only servers in possession of the private key can decrypt the master-key and derive session keys from them.
CAs, on the other hand, actually sign the certificates. A CA cannot validly deny that it signed for the authenticity of a server certificate.
Can I purchase a single SSL certificate for domain A and sign all of my other domains with the domain A as reference.
Will it work ?
You certainly can install those certificates. However just as with self-signed certificates the main problem is that they cannot be validated by browsers due to a broken verification chain.
In short: it won't work as you desire.
No, you can't. The certificate for SSL is issued with specific allowed usage (which is encoded in the certificate). This does not includes signing other certificates.
Consequently though you technically will be able to sign certificates for other domains using the key of certificate A, such signed certificates will not be validated right and will not work.
I think you're looking for wildcard certificates. Issuing a cert for *.mydomain.com would be valid for sub1.mydomain.com, sub2.mydomain.com, etc.
If you're looking to get a cert for mydomain.com and use that to generate a cert for otherdomain.com, that won't work.
FYI, wildcard certs are more considerably more expensive from what I remember.
EDIT:
Rereading your question, you want to do second option, and no, you can't do that. You'll wind up with an invalid cert and most browsers put up giant warning signs that the cert isn't from a trusted source. It will reference your cert for domain A as a trusted signer, which it is NOT, even though it WAS issued by a trusted signer further up the chain. If what you wanted to do was possible, the entire trusted signer/TLS infrastructure would be useless. (The utility of basic TLS as a verification that you're dealing with whom you think your dealing is debatable since it's trivial/inexpensive to get a cert. Hence the existence of Extended Validation Certificates.)
You can not sign further certificates from your certificate. Otherwise you could sign somethign like www.paypal.com under your own legitimate SSL certificate - This was demonstrated as possible via a MITM attack at a blackhat conference but this has since been rendered no possible.
However you can get Multi-Domain certificates. These certificates allow you to include additional domains in the SAN field (Subject Alternative Name). So the certificate is generated for a single domain and the additional domains are added during the enrollment process with your SSL provider. You will need to verify ownership of each domain you request.
These certificates allow you to host multiple FQDN on a single IP with one SSL certificate.
In addition there are also wildcard certificates but these only let you secure *.domain.com with a single certificate.