 Okay, we can start. First of all, I would like to remind you, there are lightning talks right after this presentation and now please welcome Stanislav with his presentation of HTTPS certificate not trusted. Hello, welcome everybody. I didn't expect so much people so I'm glad you came. Let me introduce myself. My name is Stanislav Židek and I'm working at Quality Engineering in Red Hat. In our team we are dealing mostly with security related packages and we are kind of concentrating a lot on testing SSL and TLS. But today my talk is going to be really like beginner oriented. Don't expect anything fancy. I just got an idea like this is something that happens to everybody and if like someone wants to know more what's happening it might maybe be beneficial to give some basic overview of what's happening. Okay, so the topic is HTTPS certificate not trusted which probably everyone has sometimes seen in their browser while connecting to some probably badly configured server but maybe it doesn't have to be that way. A bit about motivation like we are doing that because this is like the thing you can really see with your own eyes even if you are not expert in public infrastructure and such things. What we want to achieve here is like get some better understanding of what's happening under the hood and how we want to get it there. We want to get a bit more familiar with some command line tools that can help us debug some common problems that happen all the time. As I already said it's really for beginners so don't expect anything fancy. Let's start with a bit theory so what we are basically going or what we want to address or why we have the problems is because we want to address the key distribution problem when we want to communicate securely. What we use like let's go from bottom up so we start with public key cryptography which is a great thing and it helps us with the key distribution like really a lot because like we don't have to find some secure channel to exchange some secret key with someone and then use it and keep it secret all the time. It makes it easier like a lot of easier I can go to you and say like here is my public key everyone else you can see it no problem but after you see it you can kind of communicate to me securely. So this is a huge help with key distribution but it doesn't address it like whole. The problem is like you cannot be really sure it's my key like you can be if I now show it to you but you probably cannot when you see it just somewhere on the Internet and there will be written OK that's key of standard everyone trusted it might have been some attacker or anyone. So the next step is like the certificate certificate is a thing that tries to bind some other information to that public key like to associate it with some data and more like someone attests that it's correct. So typically I will take my public key I will take I will put some information to that like it's it's mine it's valid since then and it's used for I don't know what. Give it to some certification authority which in theory some kind of institution that like other people also will trust. Certificate authority sign this certificate like after some checking that it's really mind key and so on and after that theoretically I can put this certificate and everyone who downloads it can check like OK this key belongs to standard. And it was attested by this certificate authority and I trust this certificate authority therefore I can be sure to communicate with him with this public key. One step further this is not as simple like those certificate authorities can can be used like transitively. So even if you are a certification authority you you can like not be known to everybody but you can be attested by other certificate authority who signs again your public key or you create your certificate. And like if then like even the certificate authority can be trusted because someone trusts the upper level certificate authority. So how it typically looks like or what should the structure be like there should be some route certificate authority which ideally everybody should trust. Then then there should be some intermediate certificate authorities might be one might be none might be theoretically a lot of them which you don't have to know if the chain is OK like you only need to trust the route one. And one of those intermediates like it can go by a lot of levels could sign your server certificate because the server is the entity you want to trust when you are connecting somewhere. So typically you are connecting to your bank you want to know you are really connecting to your bank so no one steals your credentials. And this is how you check it. In practice those certificate authorities you trust are typically somehow pre-installed in your system. Typically in browser or somewhere else in the system because not only HTTPS is using them but the whole situation could get really complicated. And so let's have a look at at least some like basic examples what could go wrong. OK first situation I am connecting to server in this case localhost but it could have been any server like in this presentation localhost is the thing I want to connect and I want to achieve. I see this warning in Firefox this warning actually doesn't say much but we are experts we want to debug so we click advanced to see what's happening and we got error code saying something about bad domain. You can probably guess what it might be but let's have a deeper look in that command line as I promised. So what shall we do. Let's first retrieve those certificates that the server serves us and we can do that quite easily with open SSL command which has a lot of useful sub commands some of them used for debugging. For example for example here the S client it's like TLS client that can help you debug something. We can specify where should it connect. The important thing is that second argument the show search which will make the S client like print the whole certificate chain normally it only writes the server certificate. So here we can see everything it will be useful not in this example but later. And possibly if you for example debug some other certificates on your localhost or you are debugging some more complex scenarios when there are more certificates at the same IP. You can specify the server name and like it's connected with server name indication and so on and we don't have time to get into it so we can forget this one for now. Okay so I connected to that server again and I can see that something is wrong. Here I am expecting to be connecting to localhost but the certificate that's being served has the subject. Here the S means subject it's like the identification and there is some other name than localhost. So that was easy. There was like even the indication in the S client but we can get a bit deeper like if we take this blob this begin and certificate. Like this thing we can for example save it into file and we can get some more information about this certificate which might get useful. Like not here here it's obvious but anyway let's have a look what's there. We will use another sub command of open SSL. We tell him like we want to see like what's in the certificate. We are not interested in blob that's the null out and we specify the file where we save this certificate. And when we print it we actually get what we expected. There are that attributes there are that should be in the certificate and the one that's interested is as I said in the subject and there is the name that we are not expecting because we are connecting it to some like different server. A slight note here I am practically lying to in this example like normal way of doing these things is through the subject alternative name extension. So probably when you see a new new certificate like the software is not really taking care about what's in subject. It's looking in the one of those extensions because certificates have a lot of extensions and this is kind of important one and it has like the advantage you can specify more names there or anything. So that's usually the first thing you want to check. This is like old behavior. Okay let's get to next example. This one is simple again. We are seeing the same warning but after the clicking the advanced button in Firefox we see expired certificate which is probably again obvious but let's see what's happening inside anyway. We get the certificate again with the as client command as I showed in the previous example. And here when we again inspect it with X509 command we can see like the validity period is wrong. Every certificate has to have some validity period and it should be valid only in these times and here you can see that the certificate like it's okay but it was valid like two years ago. If there was 2017 everything should have been okay or 218 it's already passed, half passed one. Okay these were simple examples. Now let's get into some bit more complex ones. Now we will not be so interested in the attributes of the certificate that much. We will be more interested in the certificate chain. The thing that's related to public infrastructure I told before like certificate authorities signing some intermediate certificate authorities and so on. Again there might be problems, certificates might be different and so on. So this is kind of generic error which tells us basically that there is something wrong with certificate chain but we don't know what and there can be like many situations when this happens. So let's look at the first one. This is again like shortened output of a client command and here we see that the server serves us only one certificate and it's like self-signed by itself. This is again something you don't see that much but it's definitely like the server is not even trying to serve you something that you should trust. Because there is not even an attempt to give you some certificate authority that might be installed in your browser. So this cannot be trusted at all at least in default configuration. You can make it but anyway. Problem might be different. This one seems a bit better. Now you see the server is serving the server certificate that the first one we omitted this so it fits into the slide and it also serves the certificate authority certificate and it kind of creates the chain. Here the problem is that like it's indicated in the command name that this certificate authority is something unknown to your system or to your browser. So therefore even if this chain is okay you have nothing to compare it with everybody can create some certificate authority. The goal is when you have some public server usually to have it signed by some by some CA that is pre-installed in browsers that like you can attest somehow. Anyway even if this example doesn't work we can at least check that the chain is correct that the server certificate is really signed by this certificate authority. And this is the third and last open SSL sub command we will use today and it's open SSL verify and here we will typically specify like give him the certificate authority certificate in a file and here the server certificate. We are practically here telling the open SSL verify command that okay what's in that CA file let's pretend we trust it by default and just check the certificates that are like being thrown here. And here you can get this output if the chain is constructed well that okay the chain works so you can kind of imagine that the problem would be that you are not trusting just that CA. You can import it in the browser and in that moment everything could start working fine because now you trust it chain is correct you can connect to the server and so on. Situation might be different even though like you can still see something like this the certificate authority can be for example some other one someone generated something with the same metadata but different key and so on. And then if you run the same open SSL verify command you will get an error and now you can kind of see that okay there is some server certificate there is some CA certificate but like that server certificate is definitely not signed by that CA one. So now you see like there is the problem in the chain and it's like doesn't even link together. Even if you would have trusted that unknown CA in here like server is serving you something bad and you are not going to help yourself it can be even more different. Let's again imagine that that that error we had for the last time the unknown issuer. Here you see you are getting like again server certificate for local host but that is being signed by some let's let's say intermediate certificate authority. It's nice to see it in the name like normally you should debug to like see that it is some intermediate certificate authority and this example starts to be maybe a bit more tricky. That's quite common for example when some certificates on some servers change that even though there is some like longer chain typical server server certificate intermediate CA root CA even if you trust trust the root CA it might not be enough because for you to be able to verify it. You must see or you must have the intermediate certificate somewhere so you can construct the whole chain towards the root CA. And here like this situation is interesting because that's that's something like I cannot connect to the server like there is some certificate problem. Can you try it and other people could be like yeah I can connect like there without any problem so so what's happening. What's usually happening is that your system or your system if you have the problem you don't know that intermediate certificate and this that people for whom it works. They have it for example cashed somewhere in a browser or some NSS database or anything so even though like you are getting correct certificates server here is not providing enough information for everybody to be able to verify it. And like it's interesting that it might work for someone. It usually works for people who already saw that intermediate certificate somewhere before it got cashed but it doesn't work for example for people who didn't see it fresh install anything even though it practically it's the same. Here it's definitely the server's fault because it's not serving the whole chain. It should always send the server certificate and all the intermediate certificates linking to some root CA that browsers should trust. If you want to verify that like more complex certificate chains and when you want to somehow indicate like OK I want to trust a certificate authority this one. But then there are some some other intermediate search and I want to see if it like links down to the server certificate I want to test. You could you could use option again for open SSL verify untrusted where you kind of provide him the cash that your system might have. So this command practically makes sure that while trusting only this root root CA certificate you can like link it together to this server certificate. If you know these intermediate certificate authorities and that's how you check like the situations that are a bit more complex OK it was fast. It was just in time conclusion is like we have only talked about some really basic typical problems I wanted to you to see the commands you can use in command line because we are kind of hackers. We want to dig in command line. The one wants clicking and so on. But the reality is much more complicated if only those were the issues like probably everybody would be happy. There are many things where it can be much more complicated. There can be some bad extensions. For example that server alternative name are already talked about browser behavior might change like some certificates that work before doesn't have to work like after a new version of browser. Even the same certificates issued like on different dates might not work because some browsers are programmed like if the certificate was issued before this date. We are allowing this but not after this date. They are like in general they are trying to make the situation like more strict to get some better overall security. But again it may cause some problems. If you are interested in this topic we could definitely have a chat. Possibly if you are probably some kind of student looking at some project we can most probably make something together. You can do some verification of your own dig deeper.