We have done client certificate authentication via SSLVerifyClient require method. Now authentication is being done as required.
Now we want to store the client certificate which we is being presented by the client during SSL handshake.
Is there a way I can save the client certificate which I am getting during authentication into a directory or somewhere? I need to get the public key and CN information from the client certificate.
Apache provides the full certificates and extracted parts of it using a variety of environment variables, like SSL_CLIENT_CERT for the full certificate or SSL_CLIENT_S_DN for the subject DN. See the documentation for more details on this.
Related
We have a K8S service leveraging NGINX and in some flows would like to accept client certificate authentication.
Service has a dynamic list of public trusted client certificates (PEM format), and the root CAs aren't known.
In NGINX, it seems like the best setting to use would be:
nginx.ingress.kubernetes.io/auth-tls-verify-client: optional_no_ca
While sending the full certificate ($ssl_client_escaped_cert) to the upstream service to compare the entire public cert.
The question is whether NGINX will still perform the client cert validations during SSL handshake (and only skips CA checks), to verify the request is indeed sent by the one and only owner of the cert and its private key.
It will still check in the TLS handshake that the public key in the certificate can be used to verify the signature in CertificateVerify, i.e. that the client actually owns the private key to the sent certificate.
It will not check that the certificate itself is issued by a trusted CA etc - such verification are expected to be done elsewhere.
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.
I secure successfully a Nifi Node (localhost) with SSL but I have always a yellow padlock in my browser as you can see in the pic here
Do you have any idea?
Thanks
If you used an untrusted certificate then this is expected behavior. You would have to purchase a real certificate for a real domain name in order for the browser to not warn you.
I see the description below:
Standalone : generates the certificate authority, keystores, truststores, and nifi.properties files in one command
Client/Server mode : uses a Certificate Authority Server that accepts Certificate Signing Requests from clients, signs them, and sends the resulting certificates back. Both client and server validate the other’s identity through a shared secret.
Standalone and client, both generate the certificate authority, keystores, truststores.
Sorry, I don't see the difference.
It must be something really simple but right now I am not getting anywhere with this (I am not a network geek but a programmer).
We are trying to secure web services created between our server and a vendor. Our vendor is asking to send them the public key for an SSL certificate to secure requests and responses in our web services.
What I did
I forwarded the following to our hosting provider but they only provide SSL certificate for websites and didn't give any clear clue to what to do next.
Create a Certificate Signing Request (CSR) with any CN
Have CSR signed from CA
Merge the signed cert file with the CSR to create the actual
certificate
Extract the public and private certificates
What I need
All I need simple set of instructions to what I should do or where can I get/purchase this certificate.
Thanks,
I've been googling like mad trying to figure this out, but the answer doesn't seem to be clear, or at least, it seems like there are contradictory answers.
I'm tasked with setting up an Apache web server with 2Way SSL authentication. We use verisign to get our certificates, so we have a certificate for the web instance with the correct hostname details, signed by verisign, and an intermediate certificate from verisign. This all works very well.
Now, we need to set up a 2Way SSL connection. The initial expectation is that the client will manage their own certificates, and provide them to us for authentication. More than one client may be connecting, and they should each have access to different resources when they connect.
From what I've read, I'm not sure how this would be done...
This is a pretty good overview, but in this situation, they are using self-signed certificates: https://security.stackexchange.com/questions/34897/configure-ssl-mutual-two-way-authentication
Using these details, it would seem like we would have to make the trusted CA point to the certificate authority that signs the client's certificate.
Is it possible to use the client certificate as the trusted CA (even though it isn't self signed, but signed by a CA) or would we have to put a trusted CA from their signer (and at that point, would a CA bundle that includes all the client certificate authority CAs work?) on the server and then use the SSLRequire statements to limit access to specific details of the certificate?
As a followup, can we use the SSL Certificate that we get from verisign to sign client certificates?
So, after several more hours on google, and some testing, I was able to figure out what I needed to.
If I want to use a certificate signed by verisign or some other public CA, I would have to copy their public intermediate certificate (the one that they use to sign the client certs) to my server and specify it as the SSLCACertificateFile in the configuration. The caveat is that then any cert signed by that CA would be accepted, and that's where the SSLRequire directives can used to narrow that down to specific certificates.
Using the SSLVerifyClient optional_no_ca directive would make it assume that the cert is trusted, even if it isn't, and then I would have to use SSLRequire directives to verify the details are correct, however, anybody could create and sign their own certificate with those details and there would be no way to tell.
Creating my own self signed CA certificate, and then using that to sign the client certificates and issuing them to the clients is the only way to both ensure that the cert isn't a forgery and not requiring SSLRequire directives to ensure that only the people that I specify can connect.
Please comment/correct me if I'm wrong on any of this.
Use:
SSLVerifyClient optional_no_ca
In your Apache config. This will request the client certificate but not validate it against a CA. It will then be up to your local script to examine the resulting environment variables set by Apache such as 'SSL_SERVER_S_DN' and decide whether to allow the request or not.
These mod_ssl environment variables are also what your code needs to look at when determining what resources the client can access.
The full documentation is here mod_ssl although you probably found that already.
A note on client certificates. If you did want to use a CA and leave it to the clients, they may all use different CA's and you would have a job maintaining them all on your server. It would be much better to trust a single CA.
The advantage would be that then you could use the build in SSL support to do all your certificate checks and not write your own solution.
You could enforce a single CA by specifying an on-line provider and using email signing certificates to identify clients. These would work fine, just the Certificate Subject would be an email address instead of a domain name.
Or you could set up your own CA and sign client certificates yourself. This is not too difficult and gives you complete control. Either route would require you to add the CA root certificate (plus intermediates) to a file Apache can read and point 'SSLCACertificateFile' to it.