1

I've been working on making an SSL server/client on C++ using Boost. To load the certificates, I use the following code for each side:

server.cpp

boost::asio::ssl::context ssl_context(boost::asio::ssl::context::tls);

ssl_context.use_certificate_chain_file("server.crt");
ssl_context.use_private_key_file("server.key", boost::asio::ssl::context::pem);
ssl_context.use_tmp_dh_file("dh2048.pem");

client.cpp

boost::asio::ssl::context ssl_context(boost::asio::ssl::context::tls);
ssl_context.set_verify_mode(boost::asio::ssl::verify_peer);

ssl_context.load_verify_file("server.crt");

If I don't add the ssl_context.load_verify_file("server.crt"); line on the client, I get the following errors from both sides during SSL handshake:

server: handshake: tlsv1 alert unknown ca

client: handshake: certificate verify failed

So, is it safe to distribute the "server.crt" certificate chain file with the client? If not, how should this be done instead?

1 Answer 1

1

The problem is that your server certificate is either self-signed, or signed by an untrusted certificate authority. I'm guessing that when you created the certificate, you just did it yourself in OpenSSL, and you did not have it signed by a legitimate trusted certificate authority. Because it lacks a legitimate signature, your client has no way to recognize the certificate is valid, which is why the client sees the "certificate verify failed" error.

To fix this, there are a few options.

  • The best would be for you to replace your server certificate with a new one signed by an actual Trusted Certificate Authority (one that your server and client already trust). That way both your server and client will be able to trust your certificates and each other; now, and into the future.
  • An option that provides no security is to continue to include the server certificate with the client. It's convenient, but it directly ties your clients to only that server and certificate. Your clients will break when your fake server certificate expires, and they'll have to come to you for a new certificate. What's to stop an attacker who says he's distributing a copy of your software, including his own certificates, promising that it's secure? Nothing. Your certificates provide no assurance that the client and server are genuine and are run by you.
  • A third option (that is even less secure) is to import a copy of your signing certificate into both your server and client's trusted root authority stores. It's less secure because it exposes your clients to risk, because they'll then trust anything signed by your little fake certificate authority. I would only recommend this as a good way to learn how certificates and certificate authorities protect your communications; I would not recommend this as a long term solution.
1
  • In the scenario of mTLS (server has it's own cert and key, client has it's own cert and key), by using a Trusted Certificate Authority one could revoke client side certs? I'm struggling to find an option to revoke client side certs or simply rotate them for security reasons...
    – Mecanik
    Dec 4, 2022 at 6:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .