Generate SSL certificate, chain file, dh and key for boost::asio::ssl::context
Hi, I think I can use openssl to generate those self signed files, correct? I saw some programs use 4 use_certificate_chain_file, use_certificate_file, use_private_key_file and use_tmp_dh_file in both server and client sites, but I also saw some test program only use one ca.pem in client site and 3 use_certificate_chain_file, use_private_key_file and use_tmp_dh_file in server site, which is correct or better? Any guideline? Thank you.
Hey, On 25 February 2017 at 12:37, jupiter via Boost-users < boost-users@lists.boost.org> wrote:
I think I can use openssl to generate those self signed files, correct? I saw some programs use 4 use_certificate_chain_file, use_certificate_file, use_private_key_file and use_tmp_dh_file in both server and client sites, but I also saw some test program only use one ca.pem in client site and 3 use_certificate_chain_file, use_private_key_file and use_tmp_dh_file in server site, which is correct or better? Any guideline?
Yes, you can use openssl to generate self signed certificates. If you need to, you can also easily get widely trusted certificates for free from letsencrypt. As for using server certificates and/or client certificates: it really depends on the application. With TLS, both endpoints of the connection *can* identify themselves with a certificate. In general it makes sense to use a certificate to have the client verify the identity of the server. If the server should only accept connections from trusted users/devices, you could use client certificates too. On the other hand, if the server accepts anonymous connections, there is nothing to be gained from verifying the client certificates so you're better off not asking for them in the first place. -- Maarten
As for using server certificates and/or client certificates: it really depends on the application. With TLS, both endpoints of the connection *can* identify themselves with a certificate. In general it makes sense to use a certificate to have the client verify the identity of the server. If the server should only accept connections from trusted users/devices, you could use client certificates too. On the other hand, if the server accepts anonymous connections, there is nothing to be gained from verifying the client certificates so you're better off not asking for them in the first place.
It is a server / client TCP communication, I'll use by port of SSL although
the TLS should also work. Our server should only accept connections from
our trusted client of devices, so I should use the client certificates.
Could you elaborate in what circumstance that is possible "if the server
accepts anonymous connections"? The server does not know who requests a
connection from the SSL port, but the server will accept the connections if
the client certificate and key are valid. I thought as long as the SSL is
used, the server can only accept trusted connections, so I am not quite
understand if the server could accepts an untrusted anonymous connections.
Thanks
On Sun, Feb 26, 2017 at 12:45 AM, Maarten de Vries
Hey,
On 25 February 2017 at 12:37, jupiter via Boost-users < boost-users@lists.boost.org> wrote:
I think I can use openssl to generate those self signed files, correct? I saw some programs use 4 use_certificate_chain_file, use_certificate_file, use_private_key_file and use_tmp_dh_file in both server and client sites, but I also saw some test program only use one ca.pem in client site and 3 use_certificate_chain_file, use_private_key_file and use_tmp_dh_file in server site, which is correct or better? Any guideline?
Yes, you can use openssl to generate self signed certificates. If you need to, you can also easily get widely trusted certificates for free from letsencrypt.
As for using server certificates and/or client certificates: it really depends on the application. With TLS, both endpoints of the connection *can* identify themselves with a certificate. In general it makes sense to use a certificate to have the client verify the identity of the server. If the server should only accept connections from trusted users/devices, you could use client certificates too. On the other hand, if the server accepts anonymous connections, there is nothing to be gained from verifying the client certificates so you're better off not asking for them in the first place.
-- Maarten
On 26 February 2017 at 01:32, jupiter
It is a server / client TCP communication, I'll use by port of SSL although the TLS should also work. Our server should only accept connections from our trusted client of devices, so I should use the client certificates.
In that scenario it does indeed make sense to use both client and server certificates and have each side of the connection verify the certificate of the other endpoint. SSL is a deprecated standard. TLS is the successor of SSL. Most programs/libraries nowadays support TLS even if the API or configuration uses the name SSL everywhere. Judging from the ASIO docs, it supports TLS (though not version 1.3): http://www.boost.org/doc/libs/1_63_0/doc/html/boost_asio/reference.html#boos...
Could you elaborate in what circumstance that is possible "if the server accepts anonymous connections"? The server does not know who requests a connection from the SSL port, but the server will accept the connections if the client certificate and key are valid. I thought as long as the SSL is used, the server can only accept trusted connections, so I am not quite understand if the server could accepts an untrusted anonymous connections.
By anonymous connection I mean an unauthenticated connection. If the server requires the client to present a valid certificate, you have a form of authentication so the connections are not anonymous. You may wish to read some TLS best practises written by others who know more about it then me: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practic... -- Maarten
Thanks Maarten, appreciate your kind explanations and links.
On Mon, Feb 27, 2017 at 3:49 AM, Maarten de Vries
On 26 February 2017 at 01:32, jupiter
wrote: It is a server / client TCP communication, I'll use by port of SSL although the TLS should also work. Our server should only accept connections from our trusted client of devices, so I should use the client certificates.
In that scenario it does indeed make sense to use both client and server certificates and have each side of the connection verify the certificate of the other endpoint.
SSL is a deprecated standard. TLS is the successor of SSL. Most programs/libraries nowadays support TLS even if the API or configuration uses the name SSL everywhere. Judging from the ASIO docs, it supports TLS (though not version 1.3): http://www.boost.org/doc/libs/1_63_0/doc/html/boost_asio/ reference.html#boost_asio.reference.ssl__context
Could you elaborate in what circumstance that is possible "if the server accepts anonymous connections"? The server does not know who requests a connection from the SSL port, but the server will accept the connections if the client certificate and key are valid. I thought as long as the SSL is used, the server can only accept trusted connections, so I am not quite understand if the server could accepts an untrusted anonymous connections.
By anonymous connection I mean an unauthenticated connection. If the server requires the client to present a valid certificate, you have a form of authentication so the connections are not anonymous.
You may wish to read some TLS best practises written by others who know more about it then me: https://github.com/ssllabs/research/wiki/SSL-and-TLS- Deployment-Best-Practices
-- Maarten
participants (2)
-
jupiter
-
Maarten de Vries