Skip to content

Commit

Permalink
Merge pull request #129 from International-Data-Spaces-Association/ch…
Browse files Browse the repository at this point in the history
…ange_ca_to_support_ocsp

CA: changing to CFSSL as CA with OCSP support
  • Loading branch information
Sonia-IDSA authored Feb 8, 2024
2 parents 3ffe3f8 + 00a8d7a commit 6d5d9ac
Show file tree
Hide file tree
Showing 128 changed files with 1,767 additions and 1,140 deletions.
14 changes: 14 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,20 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
### Security
- none

## [1.2.0] - 2024-02-08

### Added
- Added script to generate PKI certificates for IDS-testbed using CFSSL
- Created new IDS-testbed certificates for the deployment of the components

### Changed
- Certificate Authority using CFSSL
- CA certificates include IP Addresses and Subject Alternative Names to the created certificates
- Changed IDS-testbed component's certificates with new CA provided certificates
- Updated `CertificateAuthority/README.md` file to highlight the new CFSSL process for certificate generation
- Updated docker-compose nginx version to 1.25.3 and proper certificate used names


## [1.1.0] - 2022-12-15

### Added
Expand Down
188 changes: 115 additions & 73 deletions CertificateAuthority/README.md
Original file line number Diff line number Diff line change
@@ -1,113 +1,155 @@
# Certificate Authority (CA)

## Link to the current specification
Official

Internal Preparation
latest version in the slideset on the certificate policy presented in the working group meetings, can be found attached to the WG Certification meetings: https://industrialdataspace.jiveon.com/docs/DOC-3611

## Description

This software is intended to be used as a mock CA for test environments. It does not offer any security guarantees and must not be used in productive environments.

Please, note that this document is only required for those end users who want to create and use different certificates for the deployment of IDS-testbed components.

## Scope

This software simulates a PKI with root CAs, intermediate CAs and device certificates. Only PKIs with exactly one level of intermediate CAs are possible.
This software simulates a PKI with root CAs, intermediate CAs and device certificates, including at the device certificates the AIA (Authority Information Access) extension information.

The software supports secp256r1, secp384r1, secp521r1 as well as RSA with different key sizes. It also supports sha256, sha384 and sha512 as signing hashes.
## Generate certificates

## Dependencies
At this step, all the neccessary certificates are generated for the use of IDS-testbed components.

The software requires Python 3 and the Python OpenSSL library to be present. On Ubuntu this can be achieved by installing the package `python3-openssl`.
```
./setup_PKI.sh {FOLDER_TO_BE_CREATED}
```

## Installation
It could look something like this:

```bash
$ git clone https://github.com/International-Data-Spaces-Association/IDS-testbed.git
$ cd CertificateAuthority
$ sudo apt install python3-openssl
```
./setup_PKI.sh data-cfssl
```

## Usage

### Initialization
### Revoke certificates

Before any other operation is possible the necessary data directory must be initialized. This can be done with the following command:
```bash
python3 pki.py init
```
**Caution:** This operation removes all created CAs, sub CAs and certificates.
At this section, it is detailed the neccessary steps to manually revoke any of the previous step generated certificates.
For the already existent folder "data-cfssl", the following certificate is revoked "connectorArevoked".

### Creation of a Root CA
The steps required to revoke a certificate are detailed at the following commands which need to be executed inside "data-cfssl" folder where the certificates are located.

A root CA can then be created with the following command:
```bash
python3 pki.py ca create --common-name [CA name] --organization-name [O] --country-name [C] --unit-name [OU] --hash [Algorithm for signing]
```
It could look something like this
```bash
python3 pki.py ca create --common-name ReferenceTestbedCA --organization-name SQS --country-name ES --unit-name TestLab --hash sha512
cd data-cfssl
# Obtain certificate information to extract serial and AKI number identifiers.
cfssl certinfo -cert certs/connectorArevoked.pem
# Command to revoke the certificate
# cfssl revoke -db-config ocsp/sqlite_db_components.json -serial {SERIAL_NUMBER} -aki {AKI_CERTIFICATE} -reason={REASON}
# where AKI must be included as shown by certinfo without ":" and with all lowercase letters.
# It could look something like this for the connectorArevoked certificate
cfssl revoke -db-config ocsp/sqlite_db_components.json -serial "581921879588615033625472730240878974097738102962" -aki "c476d0aacd9379350feba7646090a46bb4384d33" -reason="superseded"
```
A list of available parameters with their defaults can be obtained by:
```bash
python3 pki.py ca create -h

### Refresh the OCSP server to include the changes

Open a terminal at "data-cfssl" folder and execute the following commands:

```
All root CAs created can be listed with the following command:
```bash
python3 pki.py ca list
cfssl ocsprefresh -db-config ocsp/sqlite_db_components.json -ca subca/subca.pem -responder ocsp/ocsp_components.pem -responder-key ocsp/ocsp_components-key.pem
cfssl ocspdump -db-config ocsp/sqlite_db_components.json > ocsp/ocspdump_components.txt
cfssl ocspserve -port=8888 -responses=ocsp/ocspdump_components.txt -loglevel=0
```

### Creation of a Sub CA
### Verify the changes against the OCSP server

The following commands performs a check against the OCSP server to verify the revocation status of a certificate.

A sub CA can then be created with the following command:
```bash
python3 pki.py subca create --CA [CA name] --common-name [Sub CA name] --organization-name [O] --country-name [C] --unit-name [OU] --hash [Algorithm for signing]
```
It could look something like this
```bash
python3 pki.py subca create --CA "ReferenceTestbedCA" --common-name "ReferenceTestbedSubCA" --organization-name SQS --country-name ES --unit-name TestLab --hash sha384
openssl ocsp -issuer ocsp/ocsp_components.pem -issuer subca/subca.pem -no_nonce -cert certs/{CERTIFICATE}.pem -CAfile subca/subca.pem -text -url http://localhost:8888
```
The CA used for signing the sub CA is a required parameter.

A list of available parameters with their defaults can be obtained by:
```bash
python3 pki.py subca create -h
It could look something like this:

```
All sub CAs created can be listed with the following command:
```bash
python3 pki.py subca list
openssl ocsp -issuer ocsp/ocsp_components.pem -issuer subca/subca.pem -no_nonce -cert certs/connectorArevoked.pem -CAfile subca/subca.pem -text -url http://localhost:8888
```

### Creation of a Device Certificate
### Extra commands for device certificates

**Creation of key pair and certificate in one step**
A device private key with the respective certificate can be created with the following command:
```bash
python3 pki.py cert create --subCA [Sub CA name] --common-name [Cert name] --algo [Key algorithm] --bits [Bits of Key] --hash [Algorithm for signing] --client --server --san-name [DNS Name] --san-ip [IP Address]
```
At this section it is included the neccessary commands in order to obtain the certificates extensions required by IDS-testbed components for their implementation.

Additionally, it can be included country name, organization name and unit name information.
```
cd CertificateAuthority/data-cfssl/certs
```

It could look something like this
```bash
python3 pki.py cert create --subCA ReferenceTestbedSubCA --common-name Example --algo rsa --bits 2048 --hash sha256 --country-name ES --organization-name SQS --unit-name TestLab --server --client --san-name ExampleDNS --san-ip 127.0.0.1
```
The Sub CA used for signing the certificate is a required parameter. The key algorithm `rsa`, bits of key `2048`, algorithm for signing `sha256` and Subject Alternative Name with DNS Name and IP Address are also required for correct interoperability between IDS-testbed components.
openssl pkcs12 -export -out connectorA.p12 -in connectorA.pem -inkey connectorA-key.pem -passout pass:password
openssl pkcs12 -in connectorA.p12 -clcerts -nokeys -out connectorA.crt -passin pass:password
openssl pkcs12 -in connectorA.p12 -out connectorA.cert -nokeys -nodes -passin pass:password
openssl pkcs12 -export -out connectorB.p12 -in connectorB.pem -inkey connectorB-key.pem -passout pass:password
openssl pkcs12 -in connectorB.p12 -clcerts -nokeys -out connectorB.crt -passin pass:password
openssl pkcs12 -in connectorB.p12 -out connectorB.cert -nokeys -nodes -passin pass:password
openssl pkcs12 -export -out daps.p12 -in daps.pem -inkey daps-key.pem -passout pass:password
openssl pkcs12 -in daps.p12 -clcerts -nokeys -out daps.crt -passin pass:password
openssl pkcs12 -in daps.p12 -out daps.cert -nokeys -nodes -passin pass:password
openssl pkcs12 -export -out broker.p12 -in broker.pem -inkey broker-key.pem -passout pass:password
openssl pkcs12 -in broker.p12 -clcerts -nokeys -out broker.crt -passin pass:password
openssl pkcs12 -in broker.p12 -out broker.cert -nokeys -nodes -passin pass:password
openssl pkcs12 -export -out connectorArevoked.p12 -in connectorArevoked.pem -inkey connectorArevoked-key.pem -passout pass:password
openssl pkcs12 -in connectorArevoked.p12 -clcerts -nokeys -out connectorArevoked.crt -passin pass:password
openssl pkcs12 -in connectorArevoked.p12 -out connectorArevoked.cert -nokeys -nodes -passin pass:password
cp connectorA-key.pem connectorA.key
cp connectorB-key.pem connectorB.key
cp daps-key.pem daps.key
cp broker-key.pem broker.key
cp connectorArevoked-key.pem connectorArevoked.key
chmod 664 broker.cert
chmod 664 broker.p12
chmod 664 broker.crt
chmod 664 broker.key
chmod 664 daps.cert
chmod 664 daps.crt
chmod 664 daps.key
chmod 664 daps.p12
chmod 664 connectorA.cert
chmod 664 connectorA.crt
chmod 664 connectorA.key
chmod 664 connectorA.p12
chmod 664 connectorB.cert
chmod 664 connectorB.crt
chmod 664 connectorB.key
chmod 664 connectorB.p12
chmod 664 connectorArevoked.cert
chmod 664 connectorArevoked.crt
chmod 664 connectorArevoked.key
chmod 664 connectorArevoked.p12
```

The created key pair is located at the folder `CertificateAuthority/data/cert`
### Extra commands for CA certificate

**Creation of a certificate for an existing key pair**
If a private-public key pair is already available on the device, the public key can be signed to gain a device certificate with the following command:
```bash
python3 pki.py cert sign --key-file [path to public key file] --subCA [Sub CA name] --common-name "Example" --client --server
```
The path to the (public) key file and the Sub CA used for signing the certificate are required parameters. The public key file must be provided in PEM format.
cd CertificateAuthority/data-cfssl/ca
openssl pkcs12 -export -out ca.p12 -in ca.pem -inkey ca-key.pem -passout pass:password
openssl pkcs12 -in ca.p12 -clcerts -nokeys -out ca.crt -passin pass:password
openssl pkcs12 -in ca.p12 -out ca.cert -nokeys -nodes -passin pass:password
cp ca-key.pem ca.key
chmod 664 ca.cert
chmod 664 ca.crt
chmod 664 ca.key
chmod 664 ca.p12
```

### Extra commands for subCA certificate

A list of available parameters with their defaults can be obtained by:
```bash
python3 pki.py cert create -h
```
All device certificates created can be listed with the following command:
```bash
python3 pki.py cert list
cd CertificateAuthority/data-cfssl/subca
openssl pkcs12 -export -out subca.p12 -in subca.pem -inkey subca-key.pem -passout pass:password
openssl pkcs12 -in subca.p12 -clcerts -nokeys -out subca.crt -passin pass:password
openssl pkcs12 -in subca.p12 -out subca.cert -nokeys -nodes -passin pass:password
cp subca-key.pem subca.key
chmod 664 subca.cert
chmod 664 subca.crt
chmod 664 subca.key
chmod 664 subca.p12
```
115 changes: 0 additions & 115 deletions CertificateAuthority/arguments.py

This file was deleted.

Loading

0 comments on commit 6d5d9ac

Please sign in to comment.