I'm trying to load multiple certificates into an SSL_CTX.
Looking at the documentation, I was able to establish SSL connection using these 2 ways:
Create an X509_STORE, add certificates to the store, and then load the cert store into the SSL_CTX using SSL_CTX_set_cert_store.
Call SSL_CTX_use_certificate(ctx, cert) multiple times
Is there a difference between these two? I saw on StackOverflow somewhere that SSL_CTX_use_certificate does not work with self signed certs? (Loading CA certificate from memory) Why? I don't see this on the documentation anywhere. (What does it mean to be self signed?)
*also for #2, does calling SSL_CTX_use_certificate multiple times replace the existing certificate? Would I need to call SSL_CTX_add_extra_chain_cert?
The X509_STORE is used for building the certificate trust chain during certificate validation. Thus, any certificates added by X509_STORE_add_cert are used when validating the peer certificate.
SSL_CTX_use_certificate instead is used to set the local certificate used for authentication against the peer, i.e. this is to set the server certificate at the server and the client certificate at the client. It must be accompanied by a function to set the private key, like SSL_CTX_use_PrivateKey. SSL_CTX_use_certificate can be called multiple times and will either replace the existing certificate or add another one: i.e. one might have both an RSA and a ECDSA certificate at the same time with newer versions of OpenSSL.
SSL_CTX_use_certificate does not work with self signed certs?
OpenSSL does not care if the certificate is self-signed or not when using SSL_CTX_use_certificate. The communication peer which receives the certificate as authentication will hopefully care though and might complain since no local trust anchor is found to validate the certificate.
Related
I need a snippet of code for a program i am writing with Boost Asio SSL.
I have a system of two clients, that connect with each other. I require them to do a mutual authentication, so, that at the end of the handshake() command, both clients can be certain that the other client has the private key to the certificate they supplied.
Both clients have a context object, lets call them ctx1and ctx2 and each client has a public certificate and a private key.
Is it possible to set up the context objects so, that when i call socket.handshake() the clients will do a two-way authentication. If not, what would be the correct way to go about to achieve my goal ?
It looks like boost just uses the OpenSSL interface.
I don't know boost much but I've implemented lots of OpenSSL internals for Perl and came to the following conclusions after reading the relevant parts of the boost source code:
To have mutual authentication with OpenSSL you have to use SSL_VERIFY_PEER on the client side and SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT on the server side. If you use only SSL_VERIFY_PEER on the server side it will only send the certificate request to the client, but silently accept if the client sends no certificate back.
With boost this would probably be:
ctx.set_verify_mode(ssl::verify_peer); // client side
ctx.set_verify_mode(ssl::verify_peer|ssl::verify_fail_if_no_peer_cert); // server side
If you set verify_mode this way it will verify the certificates against the configured trusted CAs (set with ctx.load_verify_file or ctx.load_verify_path).
If you have full control over the CA which signed the certificates (i.e. its your own CA) it might be enough for you to accept any certificates signed by this CA. But if you use a CA which also signed certificates you don't want to accept, like typically the case with public CAs, you also need to verify the contents of the certificate. Details how to do this depends on your protocol, but for the usual internet protocols like HTTP or SMTP this involves checking commonName and/or subjectAltNames of the certificate. Details like wildcard handling vary between the protocols.
Boost provides rfc2818_verification to help you with HTTP-style validation, although from reading the code I think the implementation is slightly wrong (multiple wildcards accepted, IDN wildcards allowed - see RFC6125 for requirements).
I don't know of any standards for verifying client certificates. Often just any certificate signed by a specific (private) CA will be accepted. Other times certificates from a public CA matching a specific e-mail pattern. It looks like boost does not help you much in this case, so you probably have to get OpenSSL SSL* handle with sock.native_handle() and then use OpenSSL functions to extract certificate (SSL_get_peer_certificate) and to check the contents of the certificate (various X509_* functions).
At least if public CAs are involved you should also check the revocation status of the certificates. It looks like boost does not provide a direct interface to CRL (certificate revocation list) so you have to use ctx.native_handle() with the appropriate OpenSSL functions (X509_STORE_add_crl etc). Using OCSP (online status revocation protocol) is way more complex and relevant OpenSSL functions are mostly undocumented, which means you have to read the OpenSSL source code to use them :(
One cant force other side to authenticate against you, it is up to protocol, Ieach side autenticate only against other side. Just follow manuals as http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/overview/ssl.html
ssl::context ctx(ssl::context::sslv23);
ctx.set_verify_mode(ssl::verify_peer);
ctx.load_verify_file("ca.pem");
In a server application, once a connection has been established I can grab the client certificate from the SSL * I have. Is there a way to find out which CA I used to validate that certificate?
You can use the SSL_get0_verified_chain() function for this purpose. See the documentation here:
https://www.openssl.org/docs/man1.1.1/man3/SSL_get0_verified_chain.html
Note that this function was first introduced in OpenSSL 1.1.0, so this won't work in OpenSSL 1.0.2.
This post seems on point:
Find client certificate information from server in OpenSSL
Since SSL_get_peer_certificate returns an X509 cert, I would expect that the cert chain would be included (you couldn't handle a CRL properly without it, I'd think)?
Background: I'm a complete newbie when it comes to certificates.
We have a site running at https://global.projacked.com
The certificate is issued by AWS.
All works well for most of our customers but...
One of them is experiencing the following:
And when I click on "view certificate" I see:
So the question is: can we do anything on our end to make this work?
If not: what can I tell my customer to do to make it work? Is it a question of them updating their certificate? Or might it be cause by them being in a secured network (e.g. VPN)?
Thank you immensely in advance for your help
Your site global.projacked.com is serving a valid SHA-256 certificate. The customer who has reported this issue appears to be having its HTTPS traffic intercepted and inspected by some sort of a MITM software or device (the Issuer -- apotex-CA -- on the certificate they're seeing gives it away). The MITMing entity is generating a certificate that is trusted by the customer's browser but it happens to be a SHA-1 certificate causing Chrome to complain.
You cannot do anything to fix their issue. A lot of MITM software vendors have released updates that create SHA-256 certificates to avoid situations such as this. They can probably check to see if there are updates they can install that generate SHA-256 certificates or read this or this to see if they really need to have TLS traffic intercepted and inspected. Sadly, I've seen organizations where the "solution" to this issue is to install an older version of Chrome that did not care about SHA-1 certificates and disable auto-update. After all, burying your head in the sand is very good at blocking all the noise about this little thing called security.
The certificate issuer should be able to issue a certificate under SHA-256. You'll then need to replace the certificate on the server.
Some certificate authorities can give you new cert as a re-issue of the old one, some will require CSR (Certificate Signing Request) that can be constructed based on the existing private key, which likely resides on the server too.
I'm trying to connect with one of my client to call api methods from their server, the client want to have a bi-directional commnunication, they shared their security certificate which contains CACert.crt, another file with .crt, .key, .p7b, .pfx files. Now They want us to share our certificate. I've following questions:
How I install their certificate?
How I can generate my certificate? Do I need to purchase certificate for this or I need to generate something based on their certificate?
They mentioned about DataPower public certificate. After Googling, I found Datapower is from the IBM, can I create a free certificate from it?
I'm absolutely new to this, tried to google a lot, but couldn't make much sense.
It sounds like your client wants you to use a client certificate. They've provided you with a CA for you to use; just use that to fulfill the signing request for the certificate you generate.
I'm running a small web app on an EC2 instance and I want some friends to be able to use it. I also want to make it use HTTPS, just for basic security purposes (prevent packet snooping whenever possible). Of course I am using a self-signed certificate, because my budget for this project is $0. But Chrome throws up a warning page upon trying to visit it:
Your connection is not private
Attackers might be trying to steal your information from [...]
(for example, passwords, messages, or credit cards).
NET::ERR_CERT_AUTHORITY_INVALID
This server could not prove that it is [...]; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.
Is is not true that "any encryption is better than no encryption"? On unenecrypted HTTP, I could be trying to steal information as well, and don't have to prove anything about my server identity, AND my communication can be read in plaintext by packet sniffing, but Chrome doesn't throw up any warning flags there...
What gives? Why does Chrome hate self-signed certificates so much? Why doesn't it just put a little red box over the padlock icon, instead of giving me a two-click warning page?
Edit Sep 2021 (this was applicable since 2016): Just suck it up and use one of the free key issuers. Let's Encrypt and AWS ACM will literally do it for free.
This question is not specific to chrome. Firefox and probably other browsers behave similar and in the last years the warnings even got stricter. Complaining about these warnings shows more a missing understanding of the role of certificates in HTTPS.
With HTTPS one expects encryption, i.e. private communication between the browser and the server with nobody sniffing or manipulating the transferred data. At the beginning of the encryption client and server exchange the encryption keys, so that one can encrypt the data and the other can decrypt the data. If some man-in-the-middle manages to manipulate the key exchange in a way that it gets control over the encryption keys, then the connection will still be encrypted but not private. Thus it is essential that the key exchange is protected and this is done with certificates. Only with proper checking of the certificates the client can verify that it talks to the server and not some man-in-the-middle and thus the critical key exchange can be protected.
Certificates are usually verified by
Checking the trust chain, i.e. if the certificate is directly or indirectly (via immediate certificates) issued by a certificate agency (CA) trusted by the browser or operating system.
Verifying that the certificate is issued for the expected hostname, i.e. the subject matches the hostname.
With self-signed certificates or certificates issued by a CA unknown to the browser/OS this check will fail. In this case it is unknown, if the original certificate was already not issued by a trusted CA or if there is some man-in-the-middle manipulating the connection. Being man-in-the-middle is not hard, especially in unprotected networks like public hotspots.
Because the browser can not verify the certificate in this cases it will throw a big fat warning to show the user that something is seriously wrong. If your friends know that you only have some self-signed certificate there they should also know that this is the expected behavior of the browser in this case. You also should provide them with the fingerprint of your certificate so that they can be sure that this is the expected certificate - because there is no other way to check the validity of this certificate. Note that this warning also comes once because the browser saves the fingerprint and from then on knows that your site is associated with this certificate. But if you change the certificate it will complain again.
If you don't like the trouble of teaching all of your friends how to properly verify your certificate then get yourself a certificate by a public CA. They don't need to be expensive and some also issue free certificates.
Is is not true that "any encryption is better than no encryption"?
While bad encryption might be better than no encryption, transferring sensitive data over en encrypted but man-in-the-middle connection is definitely worse then transferring non-sensitive data with no encryption. And contrary to plain HTTP you can actually detect a potential man-in-the-middle attack with HTTPS. What you can not do is find out if this a potential man-in-the-middle attack or if the non-verifiable certificate is actually the expected, because the browser has no previous knowledge what to expect. Thus a self-signed certificate is actually not that bad provided that the browser knows up-front that this site only provides a self-signed certificate. And it might also not bad if the transferred data are not sensitive. But how should the browser know what kind of data and what kind of certificate are to expect?
Because SSL/TLS are trying to solve two problems in a single stroke, but you are completely ignoring one of them.
SSL is meant to provide both encryption (between two endpoints) and authentication (where each endpoint is exactly who it says it is). This latter solution is generally meant to be solved via organizations known as Certificate Authorities (CAs), who are supposed to verify your identity before agreeing to give you a certificate. While there have been some spectacular failures of this level of trust in the past, we don't have anything better yet, and so browsers still expect to see SSL/TLS certificates to be issued by one of these Trusted authorities; if it's not, there's no way to know if you're actually talking to the party you intended to.
So, while it may be encrypted, having an encrypted conversation with someone who shouldn't be party to the conversation is actually WORSE than having a plaintext conversation with someone who SHOULD be party to the conversation.
There are a few free SSL providers out there such as Let's Encrypt that won't cause this warning and still fit in your $0 budget.
Put chrome://flags/#allow-insecure-localhost into the Chrome address bar, then select the enabled option.
The reason for the click through is to offer some protection from phishing attacks.
The $0 work-around is to create a certification authority verified by Justaskin_ (which is just a special file) and have your friends to install the public key derived from of it on their computers.
Instead, use the private key to sign your https certificate and their browsers will accept it. OpenSSL is one tool that can do this.