We are configuring HAProxy to force require Client Certificate Validation. This works well. However, we couldn't find much information about OCSP support specifically for client certificate validation. There are information about Certificate Revocation list and OCSP Stapling (which I believe is for server certificates).
So my questions are
1. Does HAProxy supports OCSP during client certificate validation?
and
2. If it is supported, can this be manually configured without requiring the OCSP URL included in the client certificate itself or possibly overriding the url on the server?
We are configuring HAProxy to force require Client Certificate Validation.
Please define exactly what Client Certificate Validation means to you. You say it works well, so my best guess is that you're generating client certificates and you have configured haproxy to require valid client certificates in order to access resources that haproxy is in front of.
However, we couldn't find much information about OCSP support specifically for client certificate validation. ... 1. Does HAProxy supports OCSP during client certificate validation?
No. That's quite simply "out of scope" for a server like haproxy. HAproxy only does OCSP stapling, and only then if you supply the OCSP response in the form of .ocsp files in the certificate directory. It's unusual to want haproxy to block TLS connections while it tries to get HTTP responses from each TLS certificate for all the reasons that OCSP stapling exists. Along those same lines, having haproxy block TLS connections from your clients while it tries to validate their certs via OCSP (or for that matter, CRLs) is not a good idea.
Update: See this thread on in the haproxy forums.
Related
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.
I know that for MTLS , both parties , Client and server exchange certificates. These certificates should be signed by a CA that both parties can trust in order to validate the certificate.
My question is , does MTLS also means in addition to verifying the certificate (if CA is trusted, leaf certificate is trusted) , either side (Server or client) can also do some additional checks like Hostname check or Whether the client connecting to the server is in the list of approved trusted entities?
Can anyone point me to the mTLS specification and what are the overheads in mTLS?
Besides what EJP has said about "MTLS" term, the TLS 1.2 specification doesn't have strict requirements regarding what information is to be checked and in which way.
It's up to the receiving party to decide if the presented certificate is to be trusted or not. This means that for example it's ok for the server to accept only certificates issued by the CA that belongs to the company that owns the server. This is how client-bank access systems often work - they accept only certificates issued by the bank and the common name of such certificate must correspond to the username provided in a web form.
Both parties are free to check any information in the certificate including direct comparison of public key hash (thus only particular keypairs will work no matter what is contained in other certificate properties).
The most up todate RFC regarding this subject is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
this is an extension to OAuth 2.0
The purpose of this document is to define a mechanism how TLS certificate is used in a context of replacing Client ID and Secret (aka, Client Credentials)
The standard establishes two mechanisms how a TLS Certificate is used as a client credential, and the associated token flows, and attributes.
The general summary of this is:
(a) Authorization Server: checks the certificate either according to PKI (signed by a valid root) The RFC does not define the options, but they are pretty self-explanatory and depend on the use case. But it can be (1) certificate is signed by a trusted root and, is not revoked, (2) individually recognize each certificate based on some logic.
(b) Resource server checks the token and client certificate (client credential, or CC), and used in the underlying TLS session. Please note that there are no validation checks concerning the certificate or its origin at TLS layer, all checks are performed at an Application layer. The resource server should, therefore, configure the TLS stack in a way that it does not verify whether the certificate presented by the client during the handshake is signed by a trusted CA certificate.
This mechanism becomes particularly interesting in some GDPR context, as it makes it impossible to share tokens between client and the server.
Overall a great feature for privacy, and improved security.
mTLS can be implemented by issuing all parties a CA certificate and adding these to all communicating parties, which is a sort of an access control list. Whoever has their CA certificate in your app's trust store is able to connect.
The trust system however is the same as with TLS in the case of a https connection - you can issue several certificates from the same CA and add the root CA certificate to the trust store of your app. It will trust all certificates issued from the same root. This is arguably easier to set up as you only have to add the app's own certificate and the CA root. However, if you want to revoke a certificate, it becomes a little more complicated.
I wrote a guide to generate certificates here:
https://thoughts-about-code.blogspot.com/2021/12/creating-a-ca-for-mtls-with-openssl.html
First:
Both server and client certificates have to be built with the same CA certificate and key
see : https://github.com/ysimonx/mtls-ssl-generator/blob/main/generate_certificates.sh
So you have to store the CA certificate on both sides :
On the server side : you can allow (this is optional) a client that provides client cert built with the same CA than its own certificate. (see rejectUnauthorized: true)
https: {
requestCert: true,
rejectUnauthorized: true,
key: fs.readFileSync("./certificates/server/serverKey.pem"),
cert: fs.readFileSync("./certificates/server/serverCrt.pem") ,
ca: [fs.readFileSync("./certificates/ca/caCrt.pem")]
}
(exemple for a fastify nodejs https self-signed certificate server)
On the client side : you can allow (this is optional too) a server that provides (or not) the same CA certificate as the client knows
curl -k --cert ./certificates/client/clientCrt.pem --key ./certificates/client/clientKey.pem https://localhost:3000/
(parameter -k : do not verify the server certificate based upon a CA authority)
or
curl --cacert ./certificates/ca/caCrt.pem --cert ./certificates/client/clientCrt.pem --key ./certificates/client/clientKey.pem https://localhost:3000/
if you want the client to match the correct CA cert used by the server
There is no 'MTLS Specification', for the very good reason that there is no such thing as 'MTLS'. You just made it up. The TLS specification, including mutual authentication, is to be found in RFC 2246 as amended.
The TLS APIs should make the peer certificate chain available to the application, so it can do any additional checking it likes.
'MTLS', insofar as it exists at all, refers to an Internet Draft for multiplexed TLS.
What is the best way to implement https security for transport without a certificate? Should I just for instance use basicHttpBinding with SecurityMode to Transport and ClientCredentialType to HttpClientCredentialType? I did it in a way described but then when accessing WSDL I have a ceritificate warning.
I don't think you can have https without a certificate. It can be a self-created one, but then the client needs to explicitly install it in its trusted store.
You cannot. HTTPS is just HTTP tunneled inside of SSL/TLS and SSL/TLS requires the use of a certificate on the server side. If this is for testing, or only use by clients that you control, you can choose to do one of these options in place of paying for a CA-issued certificate.
Use a self-signed certificate. In order for this to work without your client getting a warning, you would need to import the certificate into the clients' trust store (usually part of the browser).
Use a certificate issued by a Certificate Authority (CA) that you control and have that CA's issuing certificate (or root) imported/trusted by all of your clients. This is mos useful if you have multiple servers in your environment and you need all of the clients in your environment to trust them.
If you need external clients to connect to your servers without doing any import/trust on the clients, you will need to procure a certificate from a globally-recognized CA like Verisign.
If you want to encrypt the contents of the messages, as well as HTTPs transport security, a further option you can consider is to use message security. This encrypts just the content of the message and not the transport channel. A potential benefit of this is that the message can be secured passing through intermediate systems, whereas HTTPs is point to point
This will require an X509 certificate on the server, which as with https certificates you can either self-sign or get from a CA like Verisign
I have a server with an SSL certificate and clients with SSL cetificates, all are signed by the same CA, and the CA is trusted on the server and clients as a root authority.
However none of the clients I have tried (iphone, chrome, explorer) will send the client certificate when the server requests it, even though they all verify the server certificate fine. They all claim not to have the certificate.
When I look at the client certificate in the certificate/profile/store they all claim it is verified and legit, and all the certificates verify fine using openssl etc.
Does an SSL client certificate need a specific name or other details so that client browsers will know when to use it? Kinda of like how a server certificate has to specify the exact domain as the name on the certificate?
The server is an apache2.2 server, but I don't think its a problem on the servers end.
Client certificates must have appropriate Key Usage and Extended Key Usage extensions set. What is "appropriate" in your case, I don't know for sure but the number of variants in Key Usage is small and you can check various values yourself.
You surely haven't forgot about the private key which should be accessible on the client side, have you?
There's a summary of the key usage and extended key usage extensions to use in this document:
http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html
(Although it is for NSS, it should apply to other products.)
You could also check whether the list of accepted CAs sent by the server is configured properly. This can be seen using openssl s_client -connect the.host.name:443, for example.