Merge pull request #129 from International-Data-Spaces-Association/change_ca_to_support_ocsp

CA: changing to CFSSL as CA with OCSP support

Author: Sonia-IDSA

CHANGELOG.md

@@ -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

CertificateAuthority/README.md

@@ -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
 ```