Introduction
"To enable HTTPS on your website, you need to get a certificate (a type of file) from a
Certificate Authority (CA). Let’s Encrypt is a CA. In order to get a certificate for your
website’s domain from Let’s Encrypt, you have to demonstrate control over the domain.
With Let’s Encrypt, you do this using software that uses the ACME protocol which typically
runs on your web host."
(Source: Let’s Encrypt)
Let’s Encrypt is a great thing and has brought security to many websites through ease of use.
The certificates from Let’s Encryped are also used for this website. Unfortunately can
Let’s Encrypt only be used for domains which are accessible over the internet.
TinyELCA is an Embedded Local Certification Authority and tries to bring the HTTPS functionality
to the local intranet.
Software
TinyELCA uses the same building blocks as TinyES3
used before. Again, Mbed TLS
is used for the TLS support. And here, too, a BeagleBone Black is used for the hardware.
Why all this anyway?
If you want to transfer data securely in the intranet or another closed system, you also
need TLS here for the web server. In order for this to work, a corresponding server certificate must be
installed on the web server. These certificates are issued by a certificate authority (CA). Since
an official CA does not issue certificates for the intranet, you have to trust your own CA for this.
For example, you can create your own certification authority
with OpenSSL, but the certificates must be issued manually for the respective server.
With TinyELCA this process can be automated and the servers can request their certificates independently.
How everything works
In order to trust a security solution, it must be available in source so that it can
be verified. That is why TinyELCA is open source and the sources are available here.
Furthermore, it will be described later on how to create the finished project from
the sources if you want to do it yourself.
The functionality of the software is described transparently here, so you can decide
for yourself if the functionality of the software meets your cybersecurity needs.
Later, there are step-by-step instructions on how to set up TinyELCA.
Like TinyES3, TinyELCA is secured by user / password login of the Server System Administrator.
A 2FA login with a FIDO2 stick is under development. There is no default password and
you have to assign a password the first time you use it. The password requires at least
one uppercase letter, one lowercase letter, one number and symbols. And the total length
must be between 8-32. Only a salted hash is stored from this password. This is only the
password for the administration not for the ELCA system.
The ELCA system has his own password. This password must be assign the first time the ELCA
is used. Here the ELCA key is derived with the help of PBKDF2 and has a size of 256 bits.
In contrast to the admin password, no hash is saved here, but a file with a specific
content is encrypted with the ELCA key and stored on the SD card. If a password, for the
ELCA, is entered later, an ELCA key is generated again and an attempt is made to decrypt
the file with it. If the correct content can now be restored, the password is correct.
AES is a cryptographic algorithm used to protect the ELCA. The ELCA can be locked and
unlocked with the ELCA key.
So that a server certificate can be issued by the certificate authority (CA) at all, a
Certificate Signing Request (CSR) is required.
"Before creating a CSR, the applicant first generates a key pair, keeping the private key
secret. The CSR contains information identifying the applicant (such as a distinguished
name in the case of an X.509 certificate) which must be signed using the applicant's private
key. The CSR also contains the public key chosen by the applicant. The CSR may be accompanied
by other credentials or proofs of identity required by the certificate authority, and the
certificate authority may contact the applicant for further information."
(Source: Wikipedia)
With the system presented here, there are two ways in which the server certificate can be
created. The first option is a manual process that can only be performed by the system
administrator. The certificate signing request (CSR) is entered on the website of TinyELCA,
and the server certificate will be created. The server certificate that has now been created
must then be installed on the server. This is a viable option for test purposes, but it is
more time-consuming and error-prone for installation on multiple systems.
That is why there is a second automated option available. Here the server itself connects
to TinyELCA and transmits the CSR. The certificate is then generated by TinyELCA and sent
back to the server. This process is of course protected with an authentication to TinyELCA.
A PSK is used for authentication. After a request from the server to TinyELCA, the ELCA
system sends a random value of 16 bytes back to the server. The server now encrypts this
data with the PSK and sends it back to TinyELCA with its CSR. The 16 bytes are decrypted on
the ELCA system and compared with the bytes which was sent. If the result is the same, the
server certificate for the given CSR is created and sent back to the server. This procedure
ensures that only servers that have the PSK can get a certificate from TinyELCA.
First time use
As already mentioned, a password must be set when using it for the first time:
(Click inside the picture to expand)
After the initial setup, the login is required, with admin for the user:
(Click inside the picture to expand)
After the login the windows looks like:
(Click inside the picture to expand)
After switching on the TinyELCA, the ELCA is still locked, and must be unlocked:
(Click inside the picture to expand)
And as mentioned before, the first time, the ELCA must be initialized too:
(Click inside the picture to expand)
And the result looks like:
(Click inside the picture to expand)
After the initialization, the ELCA looks like this:
(Click inside the picture to expand)
Oops, the following files are missing here on the SD card:
- /elca/root.crt
- /elca/inter.crt
- /elca/inter.key
In order for TinyELCA to work, these 3 files have to be created. With the help of the
"Build your own CA" project
these missing files can be generated. Please rename and copy the following files
accordingly on the SD card:
<root-ca>/ca/certs/ca.cert.pem |
=> |
/elca/root.crt |
<root-ca>/ca/intermediate/certs/intermediate.cert.pem |
=> |
/elca/inter.crt |
<root-ca>/ca/intermediate/private/intermediate.key.pem |
=> |
/elca/inter.pem |
With the correct files, the ELCA looks like this:
(Click inside the picture to expand)
Should the following error still be present here, "Error, the PSK "/elca/psk.key"
could not be found.", it can be ignored for the moment. The PSK will be needed for the
automatic process later.
Don't worry that the "inter.pem" key was unencrypted copied on the SD card. When
TinyELCA is starting, the "inter.pem" key is encrypted with the ELCA key and stored on
the SD card under "inter.key". The unencrypted PEM key will first be overwrite with
zeros, and after this deleted.
In order for the certificates generated by TinyELCA to be accepted by the users' browsers, the
users must import the TinyELCA root certificate into their browsers. The Server System Administrator
can download the root certificate by clicking on the "Root Certificate" link and make it
available to the user.
Oh, by the way, if you don't use the TinyELCA's website for a minute, you will be
logged out automatically.
The manual process
The manual process will be started by using "ELCA / Create Certificate". The content of the
CSR must be copied into the text field:
(Click inside the picture to expand)
The certificate is now generated by clicking on the "Create" button:
(Click inside the picture to expand)
The server certificate can be saved by clicking on the "single" link:
A combined certificate consisting of server and intermediate can be saved via the
"chained" link.
And with a click on the "Intermediate" link, the intermediate certificate can be saved:
With the following files, the server is now able to support HTTPS:
device.key |
(private key from the server which was used to create the CSR) |
device.crt |
(chain.crt is used instead) |
intermed.crt |
(chain.crt is used instead) |
chain.crt |
(used "chained" instead of "single" to download) |
The automatic process
As already mentioned, the automatic process requires a PSK for authentication. PSK stands
for "Pre Shared Key", which means a shared secret that must be known on both sides. Therefore
create the file "/elca/psk.txt" on the SD card which contains the "password"
for the authentication.
When TinyELCA is starting, the unencrypted "psk.txt" is encrypted with the ELCA key and
stored on the SD card under "psk.key". The unencrypted file will first be overwrite with
zeros, and after this deleted.
How to build
SEGGER Embedded Studio
v8.10b was used as the compiler to build the TinyELCA.
Download
The repository can be found on GitHub at
tinyelca.
|