TLS4Developers Workshop: Hands-on-Labs
We noticed: Many software developers and some admins do not really have a solid knowledge on TLS (SSL) connections and x.509 certificates and how to handle them. On the other hand there is a growing need for them to know about due to increasing security needs nowadays. TLS is used in HTTPS / SMTPS / IMAPS / ... connections, for encrypting or digitally signing files, etc. And these technologies help to reduce attack surface.
So there is a real need to gain in-depth knowledge: That's why we started these Hands-on training lab. You will learn step by step from very basic topics to more advanced ones. You might want to use these Hands-on-Labs as your only source of new knowledge or in addition to the TLS4Developers Workshop. They are designed in a way you can also do them at home if you feel you would like to have more time for real Hands-on experience or need more practicing.
You need a machine running Linux (or maybe MacOS) as your playground
- This could be your local workstation or some machine reachable (by network) from your workstation.
- The playground machine needs internet access.
- Single exercises maybe depend on additional prerequisites. They are named there.
- The exercises probably will work on MacOS too, but maybe need to be adapted. They have been created and tested on Linux - so if you are looking for the easy way: Go for Linux.
- You might want to use Vagrant to set up a playground machine. For your convenience it cares for most of the prerequisites.
Prerequisites using Vagrant
- cd to the directory where you cloned this Git repository. (Vagrantfile provided here needs to be in your current working directory)
Prerequisites without using Vagrant
You need to care for these additional prerequisites yourself:
- On your playground machine you need an Apache Webserver (in a recent version) up and running and mod_ssl needs to be enabled.
- You need to be able to configure and restart the Apache webserver there. If you have root access, this is easy. Other permissions to do so are absolutly fine too!
- OpenSSL needs to be installed in a recent version.
- A commandline HTTP client needs to be installed on your playground machine, curl is preferred.
- Clone this Git repository on your playground machine.
Hints: Working with the exercises
- Every exercise uses a different port (to avoid port conflicts: You might want to have more than one exercise online at once.)
So be careful when using commands from your history if they are form an other exercise. Think of changing the port.
- Port numbers of chapter A start with 1, chapter B with 2.
Second digit is the number of the exercise. So:
- Exercise A.1 uses port 11443
- Exercise A.2 uses port 12443
- Exercise B.1 uses port 21443
- We added port forwardings for all of these ports in the Vagrantfile.
So if you want to do some tests with client software on your workstation: Use the same ports there. (By default they will be bound to the localhost interface.)
Chapter A: Selfsigned Certificates and a CA Created by Yourself
Now it's time to jump to the exercise you are interested in:
- Exercise A.1: Establish a connection between a client and the HTTPS server, secured by a selfsigned certificate
- Exercise A.2: Establish a HTTPS connection with a selfsigned certificate - without any certificate warning
- Exercise A.3: A Certificate Authority (CA) - created by yourself
- Exercise A.4: The Client needs to authenticate by a Client Certificate: mTLS
- Exercise A.5: Useful Commands for Dealing with Certificates and Keystores
Chapter B: Using Certificates of an Official CA
You will do similar exercises here as in chapter A, but with certifcates from an official CA. Differnce is: Browsers and other HTTPS clients have these CA certificates in their truststore by default: No need to trust them explicitly.
Additionally you will learn about intermediate certificates, also called chain certificates.
(The playground machine you are using in chapter B can be a different one than you used in chapter A.)
- You need a DNS name pointing to the IP of your playground machine.
(We will reference to it in the exercises as
- Means: If you do a
ping exercise.jumpingcrab.comif you are in a legacy network) from your workstation, make sure your playground machine answers. And if you do the same from your playground machine itself of course it should answer too.
- If you are using a test machine in a corporate network it probably will already have a DNS record.
- If you have an own domain you can add an AAAA, A or CNAME record pointing to your playground machine.
- Alternatively some providers offer DNS records for free, e. g. https://freedns.afraid.org/
- Means: If you do a
- A certificate valid for this domain name is needed and needs to be issued by an official CA.
(The DNS name above needs to be the CN of the certificate or in one of the SAN fields.)
- If you are using a test machine in a corporate network it maybe will already have a valid certificate issued by your corporate CA. (In this case: Make sure the CA certificate is distributed in the truststore of all used clients.)
- Alternatively get a cerfificate form your preferred CA. At https://letsencrypt.org/ you can get one for free.
In chapter B you will not have such a standardized environment than in chapter A. Because this is a more real-world-scenario you will use your individual domain name, certificate, ...
That's why you will need to adapt the examples given.
|Where ever you see...||Replace it by...|
||The DNS name of your playgroud machine.|
||The full path of your certificate in PEM format.|
||The full path of your chain certificate in PEM format.|
||The full path of your certificate's private key in PEM format.|