Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
tutorial:adm:caw_driver [2019/08/08 17:42] tsunami ↷ Page moved from devel:documentation:modules_crt:adm:caw_driver to devel:documentation:adm:caw_driver |
tutorial:adm:caw_driver [2022/04/11 12:28] stekld |
||
---|---|---|---|
Line 42: | Line 42: | ||
</ | </ | ||
- | In its core, CAW uses a well-known OSSL CA all with its **openssl.cnf** file and such. Therefore every configuration which can be specified in **openssl.cnf** can be made available in the CAW. CAW makes use of **openssl.cnf** as often as possible (i.e. with defaults for the **openssl req** command) and very often invokes openssl using **-batch** argument. | + | In its core, CAW uses a well-known OSSL CA all with its '' |
- | **But beware**, CAW has also its own configuration file **caw\_settings.source**. This file contains some options that need to be in sync with options in **openssl.cnf**. So if you are fiddling with **openssl.cnf**, always also check **caw\_settings.source**. | + | **But beware**, CAW has also its own configuration file '' |
Additional information can be found in one of those three places: | Additional information can be found in one of those three places: | ||
- | * In the CAW usage page. Simply invoke | + | * In the CAW usage page. Simply invoke |
- | * As a comment in the **caw\_settings.source** file. | + | * As a comment in the '' |
* As a comment in the CAW script itself (i. e. **authors**, | * As a comment in the CAW script itself (i. e. **authors**, | ||
==== Core functions ==== | ==== Core functions ==== | ||
* Self-contained CA | * Self-contained CA | ||
- | * CAW does not depend on the global | + | * CAW does not depend on the global |
* You can run different CAs just by giving each its own folder. | * You can run different CAs just by giving each its own folder. | ||
* Installation is merely unpacking a tarball and generating CA certificate and starting serial number. | * Installation is merely unpacking a tarball and generating CA certificate and starting serial number. | ||
* Handling concurrency problems | * Handling concurrency problems | ||
- | * OpenSSL CA (**openssl ca ...**) must not be invoked in multiple instances at the same time. CAW uses lockfiles | + | * OpenSSL CA ('' |
* Private key and CSR private storage | * Private key and CSR private storage | ||
* CAW archives all files it has created, including users' private keys and CSRs. Private keys all always AES-encrypted by a password which the end-user specifies. Therefore even the CA does not have an access to the private key. | * CAW archives all files it has created, including users' private keys and CSRs. Private keys all always AES-encrypted by a password which the end-user specifies. Therefore even the CA does not have an access to the private key. | ||
* Support for hardware tokens using PKCS11 | * Support for hardware tokens using PKCS11 | ||
- | * If your OpenSSL version can support your hardware token, you can use it in CAW. Only thing you need to do is to configure it in **openssl.cnf** and **caw\_settings.source** (and there is already a template for that). | + | * If your OpenSSL version can support your hardware token, you can use it in CAW. Only thing you need to do is to configure it in '' |
* Unix-like style of invocation | * Unix-like style of invocation | ||
- | * Everything that goes into the CAW is a **command line argument**. Everything that goes out of the CAW is either a output of successful operation (on **STDOUT**) or an error (on **STDERR**). | + | * Everything that goes into the CAW is a **command line argument**. Everything that goes out of the CAW is either a output of successful operation (on '' |
- | * Return code for successful operation is **0**, for error it is **1**. | + | * Return code for successful operation is '' |
* All information going to/from CAW is in **printable form**, large data mainly as PEM or base64-encoded. | * All information going to/from CAW is in **printable form**, large data mainly as PEM or base64-encoded. | ||
* Usable as a root or intermediary CA | * Usable as a root or intermediary CA | ||
Line 70: | Line 70: | ||
* When user supplies just the **SubjectDN components**, | * When user supplies just the **SubjectDN components**, | ||
* CSR signing | * CSR signing | ||
- | * User-provided CSR is checked for sufficient **signature algorithm** and for **SubjectDN components**. CAW makes sure the comparison is text-based (by regexes) and does not care about datatypes. This effectively solves usability problems with OpenSSL' | + | * User-provided CSR is checked for sufficient **signature algorithm** and for **SubjectDN components**. CAW makes sure the comparison is text-based (by regexes) and does not care about datatypes. This effectively solves usability problems with OpenSSL' |
* Certificate prolongation | * Certificate prolongation | ||
* Because CAW stores CSRs, it is possible to prolong certificate by reissuing it with new validity period. All that is needed is certificate' | * Because CAW stores CSRs, it is possible to prolong certificate by reissuing it with new validity period. All that is needed is certificate' | ||
Line 83: | Line 83: | ||
* When requesting the bundle with private key, user must specify the password he has given during the certificate creation. | * When requesting the bundle with private key, user must specify the password he has given during the certificate creation. | ||
* CRL issuing and publishing | * CRL issuing and publishing | ||
- | * CAW enables you to create CRLs just by calling | + | * CAW enables you to create CRLs just by calling |
* Housekeeping tasks | * Housekeeping tasks | ||
- | * CAW takes care of orphan files and similar things that can happen during the life of CA. All those tasks are done by **./caw housekeep**. | + | * CAW takes care of orphan files and similar things that can happen during the life of CA. All those tasks are done by '' |
==== Installation ==== | ==== Installation ==== | ||
- | - Create separate user for your authority. **Ensure that no other user can read the home directory.** This happens for example on the (open)SuSE where each home is granted to the *users* group which encompasses all users.< | + | - Create separate user for your authority. **Ensure that no other user can read the home directory.** This happens for example on the (open)SuSE where each home is granted to the '' |
[root@ca ~]# useradd -r -m -s /bin/bash authority1 | [root@ca ~]# useradd -r -m -s /bin/bash authority1 | ||
</ | </ | ||
Line 101: | Line 101: | ||
[root@ca authority1]# | [root@ca authority1]# | ||
</ | </ | ||
- | - Ensure that **caw** script is runnable.< | + | - Ensure that '' |
[root@ca authority1]# | [root@ca authority1]# | ||
[root@ca caw]# chmod 750 caw | [root@ca caw]# chmod 750 caw | ||
</ | </ | ||
- | - Create new starting serial number. This number can be, say, *01* but there is a caveat attached to this - OpenSSL then works with 8bit serial mode (**this is potentially dangerous**). Better way is to create truly random 128bit serial number as the example shows.< | + | - Create new starting serial number. This number can be, say, '' |
[root@ca caw]# cd ca/ | [root@ca caw]# cd ca/ | ||
[root@ca ca]# openssl rand -hex 16 > serial | [root@ca ca]# openssl rand -hex 16 > serial | ||
</ | </ | ||
- | - If you want to use serial number prefixes, now it is the time to set it up. **If you don't know what it is, you can safely skip this step.** Suppose the random serial was *b1676557ad077ef7144c227d16a55025*. Then we simply edit the starting serial to have our desired prefix (say, *aaaccc000*). Total length of the serial number must remain 128b, so our new serial will be *aaaccc000d077ef7144c227d16a55025*. Write it into the **serial** file. We can, possibly, overflow to the prefix | + | - **If you want** to use serial number prefixes, now it is the time to set it up. **If you don't know what it is, you can safely skip this step.** Suppose the random serial was '' |
- | - Generate your CA certificate the usual way. For how to set it up with PKCS11 crypto token, see the end of this document. **Select the appropriate private key size.** Also, there are x509v3 certificate extensions which are handy to have in the authority' | + | - Generate your CA certificate the usual way. For how to set it up with PKCS11 crypto token, see the end of this document. **Select the appropriate private key size.** Also, there are x509v3 certificate extensions which are handy to have in the authority' |
[root@ca ca]# su - authority1 | [root@ca ca]# su - authority1 | ||
[authority1@ca ~]$ cd caw/ca/ | [authority1@ca ~]$ cd caw/ca/ | ||
Line 121: | Line 121: | ||
[authority1@ca ca]$ rm ca.csr | [authority1@ca ca]$ rm ca.csr | ||
</ | </ | ||
- | - CAW folder comes with a number of empty directories. Although needless now, they are automatically used by the **caw** script for managing the authority. Do not delete them. | + | - CAW folder comes with a number of empty directories. Although needless now, they are automatically used by the '' |
- | - Check the **ca\_openssl.cnf** configuration file and configure your authority. This file is an ordinary openssl.cnf, | + | - Check the '' |
- Enable (configure) the PKCS11 engine or disable it entirely (comment it out). | - Enable (configure) the PKCS11 engine or disable it entirely (comment it out). | ||
- | - Configure | + | - Configure |
- | - Configure parameters in the **req** stanza - those are used for generating new keys and requests. | + | - Configure parameters in the '' |
- | - Configure certificate extensions in the **issued\_cert\_ext** stanza. Do not forget to set up the **crlDistributionPoints** correctly. | + | - Configure certificate extensions in the '' |
- | - Check the **caw\_settings.source** configuration file and configure it accordingly. The tricky part there is that some settings have to have the same values as in **ca\_openssl.cnf**. Again, the comments in the file will help you. The most important things to set up are: | + | - Check the '' |
- | - Configure | + | - Configure |
- | - Configure the **CA\_OSSL\_ROOT\_CHAIN** if your CAW authority is not the root authority. | + | - Configure the '' |
- | - Configure the **SubjectDN** and **CSR** validation prefixes. This also lets you set a basic policy for user's passphrase complexity. Also, set allowed signature algorithms. | + | - Configure the '' |
+ | - **If you do not use PKCS11 crypto token (that is, you want to use '' | ||
- Generate the empty CRL file.< | - Generate the empty CRL file.< | ||
[authority1@ca caw]$ ./caw create-crl | [authority1@ca caw]$ ./caw create-crl | ||
Line 158: | Line 159: | ||
[root@ca ~]# ./caw create-crl | [root@ca ~]# ./caw create-crl | ||
</ | </ | ||
+ | |||
+ | ==== Example of CAW driver configuration in Appliance ==== | ||
+ | - Create a new folder. It is possible to add more authorities to this folder. Each authority has its own caw folder, caw script and own configuration caw_settings.source and ca_openssl.cnf.In this example, use only one CA.< | ||
+ | [root@ca ~]# mkdir / | ||
+ | </ | ||
+ | - Unzip caw driver to caw directory. Caw driver can be downloaded from our git repository: | ||
+ | [root@ca ~]# unzip caw-master.zip -d / | ||
+ | [root@ca ~]# mv / | ||
+ | </ | ||
+ | - In this example we received from customer already generated CA certificate - private key public key customerCa.key, | ||
+ | [root@ca ~]# cp customerCa.key / | ||
+ | [root@ca ~]# cp customerCa.pem / | ||
+ | </ | ||
+ | - We use random random 128bit serial number.< | ||
+ | [root@ca ~]# cd / | ||
+ | [root@ca ca]# openssl rand -hex 16 > serial | ||
+ | </ | ||
+ | - It is also necessary to merge customerCa.conf file with the caw configuration file ca_openssl.cnf and caw_settings.source. | ||
+ | - Set a correct permision and owner. .< | ||
+ | [root@ca czechidm]# chown -Rf 999:998 cert-authority/ | ||
+ | [root@ca czechidm]# chmod 400 cert-authority/ | ||
+ | [root@ca czechidm]# chmod 750 cert-authority/ | ||
+ | [root@ca czechidm]# cd cert-authority/ | ||
+ | [root@ca caw]# chmod 750 caw | ||
+ | </ | ||
+ | - It is necessary to directory cert-authority mount into a CzechIdM container, because the caw script must be executable by IdM. To file / | ||
+ | - type: bind | ||
+ | source: / | ||
+ | target: / | ||
+ | read_only: false | ||
+ | </ | ||
+ | -An important part of ca is the CRL file, which must be generated regularly. CAW creates CRL by calling ./caw create-crl. Create the .service unit that will generate CRL file. Create new file in / | ||
+ | [Unit] | ||
+ | Description=CRL refreshing | ||
+ | After=network.target docker.service | ||
+ | [Service] | ||
+ | Type=simple | ||
+ | ExecStart=/ | ||
+ | </ | ||
+ | -Create a .timer unit file which actually schedules the .service unit you just created. Create it in the same location as the .service file. The service is started every hour.< | ||
+ | [Unit] | ||
+ | Description=CzechIdM refresh CRL | ||
+ | After=network.target docker.service | ||
+ | [Timer] | ||
+ | OnCalendar=*-*-* *:00:00 | ||
+ | [Install] | ||
+ | WantedBy=multi-user.target | ||
+ | </ | ||
+ | -The crl has to be available via a web proxy. First, you must mount the file in the Web Proxy container. to file / | ||
+ | - type: bind | ||
+ | source: / | ||
+ | target: / | ||
+ | read_only: true | ||
+ | </ | ||
+ | -To make the file available from web proxy it is necessary to modify a file / | ||
+ | | ||
+ | root / | ||
+ | } | ||
+ | </ | ||
+ | -The next step is to configure our crl module ca directly in IdM. Instructions for configuration in IdM are here: | ||
+ | |||
+ | |||
+ | ==== Deconfiguring default PKCS11 engine ==== | ||
+ | By default, CAW comes with a preconfigured template for the PKCS11-enabled crypto engine. In some deployments, | ||
+ | This short howto will show you how to swap preconfigured PKCS11 engine for the more usual setup. | ||
+ | |||
+ | The '' | ||
+ | |||
+ | To deconfigure the PKCS11 template: | ||
+ | - Edit the '' | ||
+ | - Comment out '' | ||
+ | - Comment out whole '' | ||
+ | - Comment out whole '' | ||
+ | - Comment out whole '' | ||
+ | - In the '' | ||
+ | - Edit the '' | ||
+ | - Set the '' | ||
+ | ==== Configuring CAW with the PKCS11 crypto token ==== | ||
+ | <note warning> | ||
+ | **DISCLAIMER: | ||
+ | * Use real hardware crypto token. | ||
+ | * Generate CA private key directly on the token (via openssl, p11-tool or such). | ||
+ | * The private key pin (and security pin) really should not be 1234 (or 123456 respectively). Use reasonably strong pins. | ||
+ | |||
+ | **If you modify the example below according to those remarks, then your setup should be secure enough.** | ||
+ | </ | ||
+ | - First, we generate the CA private key. This is not secure, but it is quicker for demonstration purposes. For more info, see the disclaimer.< | ||
+ | [root@ca ~]# openssl genrsa -out ca.key 4096 | ||
+ | </ | ||
+ | - Create the CA CSR.< | ||
+ | [root@ca ~]# openssl req -new -key ca.key -out ca.csr -sha512 | ||
+ | </ | ||
+ | - Create the CA certificate with appropriate extensions.< | ||
+ | [root@ca ~]# openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.crt -sha512 -extfile ca_extensions.txt | ||
+ | </ | ||
+ | - SoftHSM needs the key to be in PKCS8 format. The default generated from OpenSSL is PKCS5 so we have to convert it. Also, using '' | ||
+ | [root@ca ~]# openssl pkcs8 -in ca.key -topk8 -out ca_pk8.key -nocrypt | ||
+ | </ | ||
+ | - Suppose the SoftHSM is installed and configured. The SoftHSM' | ||
+ | [root@ca ~]# softhsm2-util --init-token --slot 0 --label ca --so-pin 123456 --pin 1234 | ||
+ | The token has been initialized. | ||
+ | [root@ca ~]# softhsm2-util --pin 1234 --so-pin 123456 --import ca_pk8.key --label ca --id A1B2 --no-public-key --slot 0 | ||
+ | The key pair has been imported. | ||
+ | </ | ||
+ | - We have to link our token with openssl and test the setup. If everything goes right, we get the output similar to this one:< | ||
+ | [root@ca ~]# openssl engine -t dynamic -pre SO_PATH:/ | ||
+ | (dynamic) Dynamic engine loading support | ||
+ | Success: SO_PATH:/ | ||
+ | Success: ID:pkcs11 | ||
+ | Success: LIST_ADD:1 | ||
+ | Success: LOAD | ||
+ | Success: MODULE_PATH:/ | ||
+ | Success: PIN:1234 | ||
+ | Loaded: (pkcs11) pkcs11 engine | ||
+ | [ available ] | ||
+ | </ | ||
+ | - Now create the user certificate request the usual way and try to sign it with the CA. We have stored ours in user.csr. We will also need an identifier of the PKSC11 token, which we can get by invoking '' | ||
+ | [root@ca usercert]# openssl | ||
+ | OpenSSL> engine -t dynamic -pre SO_PATH:/ | ||
+ | (dynamic) Dynamic engine loading support | ||
+ | Success: SO_PATH:/ | ||
+ | Success: ID:pkcs11 | ||
+ | Success: LIST_ADD:1 | ||
+ | Success: LOAD | ||
+ | Success: MODULE_PATH:/ | ||
+ | Success: VERBOSE | ||
+ | Success: PIN:1234 | ||
+ | Loaded: (pkcs11) pkcs11 engine | ||
+ | PKCS#11: Initializing the engine | ||
+ | Found 2 slots | ||
+ | [ available ] | ||
+ | OpenSSL> x509 -req -engine pkcs11 -CAkeyform engine -CAkey slot_0-label_ca -CA ca.crt -days 1000 -set_serial 15 -sha256 -in user.csr -out user.crt | ||
+ | PKCS#11: Initializing the engine | ||
+ | Found 2 slots | ||
+ | engine " | ||
+ | Signature ok | ||
+ | subject=/ | ||
+ | Getting CA Private Key | ||
+ | Loading private key " | ||
+ | Looking in slot 0 for key: label=ca | ||
+ | [0] SoftHSM slot 0 | ||
+ | [1] SoftHSM slot 1 | ||
+ | Found slot: SoftHSM slot 0 | ||
+ | Found token: ca | ||
+ | Found 0 certificate: | ||
+ | No private keys found. | ||
+ | Loading private key " | ||
+ | Looking in slot 0 for key: label=ca | ||
+ | [0] SoftHSM slot 0 | ||
+ | [1] SoftHSM slot 1 | ||
+ | Found slot: SoftHSM slot 0 | ||
+ | Found token: ca | ||
+ | Found 0 certificate: | ||
+ | Found 1 private key: | ||
+ | 1 P id=ffffffa2ffffffb2 label=ca | ||
+ | ^C | ||
+ | </ | ||
+ | - Then we can verify the signing was correct:< | ||
+ | [root@ca usercert]# openssl verify -CAfile ca.crt user.crt | ||
+ | user.crt: OK | ||
+ | </ | ||
+ | - This tells us that openssl integration with the PKCS11 engine is working. To configure it in CAW, edit the '' | ||
+ | - The last step is to configure '' | ||
+ | |||
+ | ==== Using SoftHSM under non-root user ==== | ||
+ | <note warning> | ||
+ | |||
+ | We are installing SoftHSM on CentOS 7 operating system. Then, we will configure it to run under authority1 OS user. | ||
+ | - Add the EPEL repository and install necessary packages.< | ||
+ | [root@ca ~]# yum install epel-release | ||
+ | [root@ca ~]# yum install softhsm opensc engine_pkcs11 | ||
+ | </ | ||
+ | - Check if there is a system-wide configuration file.< | ||
+ | [root@ca ~]# cat / | ||
+ | # SoftHSM v2 configuration file | ||
+ | directories.tokendir = / | ||
+ | objectstore.backend = file | ||
+ | # ERROR, WARNING, INFO, DEBUG | ||
+ | log.level = INFO | ||
+ | </ | ||
+ | - We have two options: | ||
+ | * Change the system-wide configuration to point to a directory the '' | ||
+ | * Create local configuration file. This is better in cases where we want to have separate SoftHSM token storages. | ||
+ | - We go for the second option. First, we change to the authority1 user and create our directory structure and config file.< | ||
+ | [root@ca ~]# su - authority1 | ||
+ | [authority1@ca ~]$ pwd | ||
+ | / | ||
+ | [authority1@ca ~]$ mkdir -pv softhsm/ | ||
+ | mkdir: created directory ‘softhsm’ | ||
+ | mkdir: created directory ‘softhsm/ | ||
+ | [authority1@ca ~]$ chmod 750 softhsm | ||
+ | [authority1@ca ~]$ vim softhsm/ | ||
+ | [authority1@ca ~]$ cat softhsm/ | ||
+ | directories.tokendir = / | ||
+ | objectstore.backend = file | ||
+ | # ERROR, WARNING, INFO, DEBUG | ||
+ | log.level = INFO | ||
+ | </ | ||
+ | - SoftHSM is managed with the '' | ||
+ | [authority1@ca ~]$ export SOFTHSM2_CONF=/ | ||
+ | </ | ||
+ | - Now we simply call the '' | ||
+ | [authority1@ca ~]$ softhsm2-util --init-token --slot 0 --label test_slot --pin 1234 --so-pin 123456 | ||
+ | </ | ||
+ | - We can check, that new token object was created in the configured backend store.< | ||
+ | [authority1@ca ~]$ find / | ||
+ | / | ||
+ | / | ||
+ | / | ||
+ | </ | ||
+ | - SoftHSM is working! To use such configuration with CAW, edit the '' |