How to revoke the SSH signed certificate before ttl in Hashicorp Vault ?
Revoking SSH certificates is currently not possible through Vault.
The main issue is that SSH certificates do not have the online revocation system that TLS certificates have (either CRL from the CA or OCSP). This means any revocation needs to be propagated through other means.
In openssh, this is done using the RevokedKeys option which points to a key revocation list. This list can contain keys or certificates to reject.
When you want to revoke a certificate, you would need to add it to the revocation list on every host that needs to reject it.
There has been at least one request to add generating certificate revocation lists in Vault but this has been closed. The recommended alternative is very short lived certificate lifetimes (enough to connect right away).
Related
I am trying to enable Mutual TLS based authentication for an application deployed in a Kubernetes cluster.
Use cases:
Want to restrict access to our application to only those users with trusted client cert.
Based on certain situations/conditions, I would also want to revoke the certificate of a specific user so that the user is no longer able to access the application with his/her certificate.
I tried setting up Mutual TLS at kuberentes ingress controller (nginx based), by adding the following annotations.
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "ca-cert"
ca-cert is the kubernetes secret containing the CA certificate used to issue client certs. In this way ingress validates the client certificate sent as part of the request against ca-cert.
This works very well for any client certs signed by ca-cert. I am trying to come up with solution for certificate revocation process. Need advice on this.
Is it possible to trust individual client cert instead of a CA Cert in ingress? This will help us revoke individual client certs.
If I understand you correctly you need to use Nginx Certificate Revocation List.
It should be done by using standard Nginx configuration (create in standard format, add to file, update the file from Ingress).
Here are more details / tutorials regarding this.
Please let me know if that helped.
So I was using Certbot to automatically renew the Let's Encrypt TLS certificate via --webroot and crontab.
The question is:
Can a TLS/SSL certificate be renewed just as usual if it is revoked for some Unforeseeable reason?
Or do I have to apply for a brand new certificate.
The revocation is done for a certificate with a specific serial number. A renewal would issue a new certificate with a different serial number. This means that the existing revocation would not apply to the new certificate even if all other parts of the certificate were kept unchanged.
Since a revocation is usually done if the private key of the certificate was compromised somehow or if the owner of the domain changed, you should make sure that the renewed certificate is not created with the old private key, i.e. not reuse the old certificate signing request but create a new one with a new private key (rekeying).
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.
I am sure this is embedded in the details of the SSL certificate/HTTPS specs but I am not entirely grokking this subject.
If a modern browser connects to a HTTPS site, the body of the HTTP request is encrypted. Is the SSL certificate essentially the "public" key used to communicate back and forth between the client and server?
Couldn't a hacker get the public key from the public site, say "https://www.google.com" and monitor client/server traffic and decrypt the data?
Also, do clients need to verify the "issuer" of a certificate. For example, self sign certificates clients don't need to verify but for certificates provided from a trusted issuer, what happens during the certificate verification process?
The server's certificate contains a public key which in fact is visible to everybody. This key in turn is used during the handshake between the server and client in order to create a unique session key that will be used to encrypt any further messages:
http://en.wikipedia.org/wiki/Secure_Sockets_Layer#TLS_handshake_in_detail
Couldn't a hacker get the public key from the public site, say
"https://www.google.com" and monitor client/server traffic and decrypt
the data?
The hacker won't know the session key. He will be listening to (senseless) encrypted stuff.
Also, do clients need to verify the "issuer" of a certificate. For
example, self sign certificates clients don't need to verify but for
certificates provided from a trusted issuer, what happens during the
certificate verification process?
Like you said, the issuer of the certificate is verified against a pre-defined list of trusted authorities. Any certificate up in the chain will be verified too, including the trusted issuer, expiration dates. Additionally each certificate contains URLs that point to Certificate Revocation Lists (CRL Distribution Points), the client will attempt to download the list from such URL and ensure the certificate at hand has not been revoked.
According to https://wiki.jasig.org/display/CASUM/X.509+Certificates,
After the Server sends the certificate that identifies itself, it then can then send a list of names of Certificate Authorities from which it is willing to accept certificates.
I am wondering how to determine what this list is, and how to modify it.
The reason I am asking is that I am getting an infinite redirect between my server and my client after successful validation (i.e., the ticket stage), and I think it has to do with the CAS server not recognizing the CAS client's certificate (the client's certificate is self-signed).
If you want to see what this list is, you can use OpenSSL:
echo "" | openssl s_client -connect your.server:port
This will show various messages regarding the handshake, including the certificates and the list of CAs in the CertificateRequest message.
Ultimately, it's determined by the active X509TrustManager's getAcceptedIssuers() method. By default, this will be the list of Subject DNs of all your trust anchors (that is, the Subject DNs of all the certificates in your trust store).
Your client certificate will have to be verified by the server. This is normally done during the handshake by the trust manager, which (unless tweaked) will build a chain to a known CA (or at least known cert if it's the user cert itself) in the trust store.
Adding your self-signed certificate to your trust store should be sufficient. It doesn't have to be the cacerts file bundled with the JVM, you could make a copy of it and use the trust store settings of Apache Tomcat's connector to set it up.