Join us and get access to hundreds of tutorials and a community of expert Pythonistas.
This lesson is for members only. Join us and get access to hundreds of tutorials and a community of expert Pythonistas.
Hosting HTTPS With Flask
00:00 In the previous lesson, I showed you how to finish the code to become a Certificate Authority. In this lesson, I’m going to show you how to use the certificate generated through the CA to host an HTTPS site using Flask. To host a web server that uses HTTPS you need: a signed certificate, configuration for Flask to use the certificate, and configuration for your web browser to include your custom Certificate Authority in its list of Trusted Third Parties.
00:30
This is a new copy of the original Flask server, not the one using the Fernet keys. The only difference between this and the original is line 13. The Flask development server is being started with the ssl_context parameter.
00:45
This tells Flask to serve HTTPS. The ssl_context requires two arguments: the server public key and the server private key. The server public key is the signed certificate issued by the CA to Alice.
01:01 The server private key is Alice’s private key that she used to create the CSR for the CA. Remember that when a private key is created, it’s encrypted with a password.
01:12 That’s going to be important in a second. In the lower window, I’m going to start up the server.
01:19
And because the private key is being used, Flask asks for a PEM pass phrase. This is the password that was used to encrypt the server private key. Typing it in allows the server to start. It’s running on port 5684 just like before, in order to be consistent. In a third window, I’m going to hit that with curl.
01:44
Uh-oh, that doesn’t look very good. What’s the problem? Well, by default, curl doesn’t know who the CA is. Charlie’s CA service isn’t in curl’s default list of CAs.
01:57
That means you have to tell curl about Charlie. You can tell curl about a different CA by passing in the CA’s public key on the command line.
02:07
You do that with the --cacert (CA cert) argument.
02:13
Well, that still didn’t work, but it’s a different error message this time. This time, it’s complaining that it doesn’t like the hostname '127.0.0.1'.
02:25
If you think back to the previous lesson, the CSR included two valid hostnames for the certificate: 'localhost' and 'alice.example.net'. '127.0.0.1' isn’t one of those valid hostnames, so the certificate doesn’t recognize it.
02:44
Even though your computer thinks localhost and 127.0.0.1 are the same thing, the certificate doesn’t. Most Certificate Authorities refuse to sign certificates for IP addresses, so you usually have to have a hostname. Third time’s the charm, this time with localhost. Still need the CA’s public key.
03:09
And there it is. shhhh, this is a secret. You’ve now successfully served your secret message over HTTPS. One thing to keep in mind is HTTPS only encrypts the channel.
03:22 It stops someone from sniffing the contents of the channel, but it doesn’t stop anyone from actually hitting the port. Anyone who’s willing to ignore a browser’s warning about an invalid certificate can still see the contents hosted on HTTPS.
03:38 You would need to combine the ideas from the Fernet code with this code to serve a secret message over HTTPS.
03:47 Congratulations! You’re now a CA capable of signing your own CSRs and hosting an HTTPS server with a self-signed certificate. In the last lesson, I’ll wrap up and show you some shortcuts that you could use to skip past all this code.
Become a Member to join the conversation.