We have a web server running on linux machine where we configured 'SSLVerifyClient' as 'require' in ssl.conf file.
Does this needs client who is utilizing the service from web browser(like firefox or chrome) needs a certificate.
If yes, then it is not possible to distribute client certificate to every user as there can be some thousands of users, how to overcome this problem.
If no, then how the data passed over network is secure? I know that certificate helps in encrypting data so that no one who don't have certificate can read data.
Please help me in clarifying my doubts
If you don't use client certificate, the https connection is still safe:
Only the client and the server can read/write the content
The identity of the server is assured by a certificate authority
Client certificate only give you client authentication in the beginning of the connection. To encrypt the data, the public key of the server is used in the beginning (See public key encryption).
If you identify the client with cookies set after login/password submit, it is still safe: you have identify the client.
When SSLVerifyClient is set to require, the client MUST pass a client certificate. You would generate these via OpenSSL, and sign them with a certificate authority that you install via SSLCACertificateFile.
How you distribute those certificates is an issue you'll have to solve yourself.
Related
I am having a doubt regarding SSL certificate. We've some third party vendor who has exposed their services but asks for SSL certifcate to be attached in request.
Our java code is deployed on Weblogic server. Now we have configured SSL certificate (complete chain) in WLS using keystore. it's done on port 9003. Now when I connect with putty to my WLS over SSH and try to curl the test url of the third party vendor, I am getting un authorized error.
Upon inquiring the same to third party vendor, they said I must send my certificate with the request.
Now my question is, if my server is configured with the SSL certificate, do I need to attach certificate with every request ?
The certificate which is used to authenticate your server against some browser and the certificate which is used to authenticate yourself as a client against another server are unrelated. While in some cases they might be the same in other cases they are different. In other words: you need to attach the client certificate which is required by the other server with each request. curl will not magically do this for you.
Currently I want to expose a gRPC Method as Public API and protected by Auth0 (JWT Token), with Istio(Envoy Proxy) will help validating the token on server side. Since the JWT Token is not encrypted by the standard (it is only used to end-user authentication and authorization layer), I want to encrypt the communication using TLS. Also, my public server already have valid certificate.
The problem is on the gRPC Client side. Every example I look, the gRPC Client have to initialize the TLS Connection with server cert pem file. Is it really necessary? Because it adds operational burden and complexity, where we have to distribute our server pem file everytime we renew the certificate AND/OR the client side has to restart the application.
Thanks,
Agung
If you are using a self signed certificate, then yes you must explicitly trust it in your client. If you use a publicly signed certificate on your Server, gRPC will use the Operating System's certificate authorities to verify the cert. (In the case of Java, it uses the JVMs cert authorities.)
If you are using a self-signed certificate you need to specify the server's root certificates in the pem_root_certs member of the SslCredentialsOptions struct passed in when creating a channel, as Carl says.
However if you are using a CA issued certificate, leaving the pem_root_certs member empty will cause gRPC to default to its own master list (reviewable online), not any OS-specific list.
I am trying to wrap my head around certificates and any help is appreciated. So far this is what I understand, please correct me if I am wrong.
When using the browser when I navigate to the https site the browser downloads the certificate(without the private key) and then continues to send the data over https?
I have come across some sites (especially when developing) that require you to install the certificate on the local machine before making a service call. What is the purpose here and how does it work?
I have also seen some scenarios where you need to install the certificate on the client machine for authentication purposes for example if you are using an email client, how does this work?
When using the browser when I navigate to the https site the browser downloads the certificate(without the private key) and then continues to send the data over https?
No, the browser and the server stablish a SSL/TLS secure channel with a symmetric encryption key. During the handshake process the server presents the https certificate and digitally signs some data with the private key as a proof of authenticity.
I have come across some sites (especially when developing) that require you to install the certificate on the local machine before making a service call. What is the purpose here and how does it work?
The client must trust the server certificate. Usually it has a list with the Certification Authorities for which certificates are accepted. For other certificates is needed to add them to the trust list. If not, the communication will be rejected
I have also seen some scenarios where you need to install the certificate on the client machine for authentication purposes for example if you are using an email client, how does this work?
Probably the same case as the previous one. Also the public part of the certificate of a user can be used to encrypt a message for him
I am working on a product that would be http POSTing some data to my server everyday. The server doesn't send any data/REQUESTS to my device (other than the HTTP status). I use a redpine wireless module RS9113 that does the connectivity piece for me. I want this communication to be https enabled and my web server already has a CA-issued certificate.
Question is :
When I do a POST from my embedded device, my understanding is that the SSL library would check the validity of the server certificate. Am I right ?
If my client doesnt need a certificate, does it mean the public key of the server is stored on the wireless module (and this is used for encryption everytime) ? I can guess that this is something I need to ask the redpine wireless folks, but can you give me a general idea how this works ?
In this setup, do I need to have any certificate ON my embedded device ? I am ok if anybody POSTs the data to the server because we have identifiers that would flush out the non-conforming structure of data. If there is no cert on the device and if we POST, does it mean that the data is encrypted from device-server ?
Bonus question : In this setup, if my cert on the server is renewed, will it cause any problems in sending the data ?
I do not know the redpine wireless module, so take this response as a resolution of doubts about SSL in general
When I do a POST from my embedded device, my understanding is that the SSL library would check the validity of the server certificate. Am I right ?
Yes, the SSL library should check that the issuer of the certificate (the root CA) or the certificate itself are present in the trust store. If you use a self-signed certificate or a CA that is not present in the truststore, you have to include the public key in the truststore
If my client doesnt need a certificate, does it mean the public key of the server is stored on the wireless module (and this is used for encryption everytime) ?
The two things are not related. You need the public key of the server in the wireless module to establish trust. A client certificate would be needed if you use two-ways authentication. The client certificate is presented during SSL handshake to authenticate the client to the server
In this setup, do I need to have any certificate ON my embedded device ?
No, if two ways authentication are not required
If there is no cert on the device and if we POST, does it mean that the data is encrypted from device-server ?
The client certificate, if any, is not used to encrypt. Is used to authenticate during the initial handshake. The handshake stablish a symmetric key used to encrypt and decrypt the communication in both sides.
In this setup, if my cert on the server is renewed, will it cause any problems in sending the data ?
Depending on the setup of the server certificate on your client truststore. If the new certificate is issued on the same side, it is enough to have imported the root CA. If you use self-signed certificate, you will need to import the new one
I am somewhat confused as to how two-way SSL works. How does the client create its certificate to send to the server? Is it generated from the server and distributed to the client?
Also, what is the advantage of two-way SSL over one-way SSL?
Both certificates should exist prior to the connection. They're usually created by Certification Authorities (not necessarily the same). (There are alternative cases where verification can be done differently, but some verification will need to be made.)
The server certificate should be created by a CA that the client trusts (and following the naming conventions defined in RFC 6125).
The client certificate should be created by a CA that the server trusts.
It's up to each party to choose what it trusts.
There are online CA tools that will allow you to apply for a certificate within your browser and get it installed there once the CA has issued it. They need not be on the server that requests client-certificate authentication.
The certificate distribution and trust management is the role of the Public Key Infrastructure (PKI), implemented via the CAs. The SSL/TLS client and servers and then merely users of that PKI.
When the client connects to a server that requests client-certificate authentication, the server sends a list of CAs it's willing to accept as part of the client-certificate request. The client is then able to send its client certificate, if it wishes to and a suitable one is available.
The main advantages of client-certificate authentication are:
The private information (the private key) is never sent to the server. The client doesn't let its secret out at all during the authentication.
A server that doesn't know a user with that certificate can still authenticate that user, provided it trusts the CA that issued the certificate (and that the certificate is valid). This is very similar to the way passports are used: you may have never met a person showing you a passport, but because you trust the issuing authority, you're able to link the identity to the person.
You may be interested in Advantages of client certificates for client authentication? (on Security.SE).
What you call "Two-Way SSL" is usually called TLS/SSL with client certificate authentication.
In a "normal" TLS connection to example.com only the client verifies that it is indeed communicating with the server for example.com. The server doesn't know who the client is. If the server wants to authenticate the client the usual thing is to use passwords, so a client needs to send a user name and password to the server, but this happens inside the TLS connection as part of an inner protocol (e.g. HTTP) it's not part of the TLS protocol itself. The disadvantage is that you need a separate password for every site because you send the password to the server. So if you use the same password on for example PayPal and MyPonyForum then every time you log into MyPonyForum you send this password to the server of MyPonyForum so the operator of this server could intercept it and try it on PayPal and can issue payments in your name.
Client certificate authentication offers another way to authenticate the client in a TLS connection. In contrast to password login, client certificate authentication is specified as part of the TLS protocol. It works analogous to the way the client authenticates the server: The client generates a public private key pair and submits the public key to a trusted CA for signing. The CA returns a client certificate that can be used to authenticate the client. The client can now use the same certificate to authenticate to different servers (i.e. you could use the same certificate for PayPal and MyPonyForum without risking that it can be abused). The way it works is that after the server has sent its certificate it asks the client to provide a certificate too. Then some public key magic happens (if you want to know the details read RFC 5246) and now the client knows it communicates with the right server, the server knows it communicates with the right client and both have some common key material to encrypt and verify the connection.
In two way ssl the client asks for servers digital certificate and server ask for the same from the client. It is more secured as it is both ways, although its bit slow. Generally we dont follow it as the server doesnt care about the identity of the client, but a client needs to make sure about the integrity of server it is connecting to.