!!! Mediawiki has been upgraded !!!
Slack integration has been disabled for now due to an incompatibility.
If you want to testdrive the new skin (Tweeki), make sure your language settings are set to 'en - English' in your preferences!


From Brixel - Hackerspace Hasselt
Jump to: navigation, search

Project: Brixel PKI
Description: Our own PKI!
Status: In progress
Participants: Johan
Expertise: PKI
Edit tags: PKI


As secure communication becomes more and more important, we wanted to start using SSL certificates to protect communication flows.

Outsourcing "trust" to a commercial Certificate Authority is never a good idea, so this project was started to built our own Public Key Infrastructure.
If you have implicit trust in "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı" or "Taiwan CA Global Root CA", we don't think there is a good reasson for not explicitly importing our own certificates to access our servers. After all, you are connecting to our server and are already trusting us there is nothing suspicious in the data we sent to you. :-)

To verify and/or import our CA certificates, please see Brixel-CA.

PKI Structure

Brixel Root-CA
├── Brixel Server-CA
│   ├── Server Certificate 1
│   ├── Server Certificate 2
│   ├── ...
├── Brixel UserAuth CA
│   ├── User Certificate 1
│   ├── User Certificate 2
│   ├── ...
├── Brixel additional CA's (Future)
│   ├── Certificate 1
│   ├── Certificate 2
│   ├── ...
├── ...

Brixel Root CA

A Brixel Root certificate was generated on a cleanly installed system with a hardware random number generator, seeded from software. The system was updated with the latest patches and brought off-line before generating the certificate. In order to be future proof, the certificate generated is 4096 bits and uses SHA-1.

The Root CA is only used to sign intermediate CA's and the private key is kept off-line for security reasons.
No usable certificates will be signed directly by this certificate.

Brixel Server intermediate CA

Contrary to the Root CA certificate, this CA certificate will be used to sign certificates.
The server CA certificate is used to generate server certificates, no client certificates will be signed by this certificate.

All "official" Brixel websites that use SSL will have certificates that are signed by this intermediate CA.

The same security measures are employed for securing this intermediate CA certificate as for the Root CA certificate.

Brixel UserAuth intermediate CA

This CA is used to create user certificates wich are used to securely authenticate users against internal services, such as administration portals, etc...

Creating a CSR

When there is a need for a client certificate, you can follow this procedure.

We could just give you a certificate, but that would imply we have access to your private key...
To keep things ethical, we ask you to generate a CSR so you generate a private key yourself. It will never leave your system and only you (should) have access to it.

When creating a CSR, the keysize of your certificate must be at least 2048 bits.

The only thing that needs to be filled in correctly in the CSR, is your (full) name and email adress. It is recommended you fill in the same email adress as used for your Brixel membership.
All other information you add to the CSR will be overwritten when your certificate is signed.

An openssl example to create a CSR:

openssl req -out Brixel_UserCert.csr -new -newkey rsa:2048 -nodes -keyout Brixel_UserCert.key

Generating a 2048 bit RSA private key
writing new private key to 'Brixel_UserCert.key'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [BE]:
State or Province Name (full name) [Limburg]:
Locality Name (eg, city) [Hasselt]:
Organization Name (eg, company) [Brixel - HackerSpace Hasselt]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:Full Name
Email Address []:Working Emailaddress

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

You must keep you "key" file secret. This is essentially your identity.

Signing your key

You will be instructed to send your CSR file and after a while you will receive a signed certificate which needs to be imported.
In the mean time, you can already import our CA certificates, which are only required if you don't want to receive the warningmessages of an "untrusted" website.

More information is located here.

Importing your certificate

After your CSR has been validated and you received a signed certificate, you should have 3 files:

  • Your private key (Brixel_UserCert.key). This has been in your possession all the time.
  • Your CSR (Brixel_UserCert.csr). This was sent to us, and we used it to create
  • A signed certificate (PEM formatted text.). This is what was sent to you by email.

You can save the PEM certificate from your email to a file on disk, example: "Brixel_UserCert.crt".

To facilitate managing and importing the certificate, you can merge the private key and signed certificate into one file and change the format to pkcs12. (Optionally, you can even add the (intermediate) CA certificates to the pkcs12 file. Brixel-CA)

An openssl example to to convert PEM files to pkcs12:

openssl pkcs12 -export -out THIS_WILL_BE_YOUR_CERTIFICATE.pfx -inkey Brixel_UserCert.key -in Brixel_UserCert.crt

In stead of the previous command, you can optionally include the CA certificates by extending the command to:

openssl pkcs12 -export -out THIS_WILL_BE_YOUR_CERTIFICATE.pfx -inkey Brixel_UserCert.key -in Brixel_UserCert.crt -certfile BrixelUserAuthCA.txt

Once the ".pfx" file has been created, you can import it into your webbrowser, or your certificate store of your operating system.


In the future there can be more intermediate CAs, for example one for VPN client certificates, user certificates, etc... This will be decided when the need arises.