It doesn't make much sense to have separate guides outside infra documentation. So let's migrate https://pagure.io/fedora-infra/howtos to infra docs. Signed-off-by: Michal Konecny <mkonecny@redhat.com>
122 lines
3 KiB
Text
122 lines
3 KiB
Text
= How to create TLS certificates for fedora-messaging
|
|
|
|
== Creating TLS Certificates
|
|
|
|
In ansible-private, find the files/rabbitmq/ folder. In that is a production
|
|
and a staging subdirectory
|
|
|
|
. Create the staging certificates:
|
|
+
|
|
In the staging subdir, run:
|
|
+
|
|
----
|
|
/usr/share/easy-rsa/3/easyrsa build-client-full <service name>.stg nopass
|
|
----
|
|
+
|
|
For example:
|
|
+
|
|
----
|
|
/usr/share/easy-rsa/3/easyrsa build-client-full monitor-gating.stg nopass
|
|
----
|
|
+
|
|
[NOTE]
|
|
====
|
|
For staging we always make the name `.stg` so that ansible scripts
|
|
work with it
|
|
====
|
|
|
|
. Create the production certificates:
|
|
+
|
|
In the production subdir, run:
|
|
+
|
|
----
|
|
/usr/share/easy-rsa/3/easyrsa build-client-full <service name> nopass
|
|
----
|
|
+
|
|
For example:
|
|
+
|
|
----
|
|
/usr/share/easy-rsa/3/easyrsa build-client-full monitor-gating nopass
|
|
----
|
|
+
|
|
[NOTE]
|
|
====
|
|
No `.stg` here.
|
|
====
|
|
|
|
. Add the certificates to the git repo:
|
|
+
|
|
Run the usual commands:
|
|
+
|
|
----
|
|
git add .
|
|
git commit -s -a -m 'Added fedora-messaging certs for <service>'
|
|
git push
|
|
----
|
|
|
|
Source: https://pagure.io/fedora-infrastructure/issue/8638
|
|
|
|
== Regenerating TLS certificates
|
|
|
|
. Revoke old certificate
|
|
+
|
|
In the staging subdir run
|
|
+
|
|
----
|
|
/usr/share/easy-rsa/3/easyrsa revoke <service-name>
|
|
----
|
|
+
|
|
Same for production, but without `.stg` in name and the commands need to be run from production subdir
|
|
|
|
. Remove the cert from `index.txt` and `index.txt.old`
|
|
+
|
|
The easiest way around this is to simply do a ``git grep <name of your cert>``.
|
|
It should tell you that the name can be found in `index.txt` (and potentially
|
|
`index.txt.old` if another certificate was generated since the first attempt
|
|
and yours).
|
|
|
|
. Follow the <<Creating TLS Certificates>>
|
|
|
|
== Debugging
|
|
|
|
If you run into the following error when during generating the certificates:
|
|
|
|
----
|
|
failed to update database
|
|
TXT_DB error number 2
|
|
----
|
|
|
|
The full output looking something like
|
|
----
|
|
|
|
Using SSL: openssl OpenSSL 1.0.2k-fips 26 Jan 2017
|
|
Generating a 2048 bit RSA private key
|
|
.+++
|
|
.....+++
|
|
writing new private key to '/..../files/rabbitmq/staging/pki/private/monitor-gating.stg.key.PhSK949Ny8'
|
|
\----
|
|
Using configuration from /..../files/rabbitmq/staging/pki/safessl-easyrsa.cnf
|
|
Check that the request matches the signature
|
|
Signature ok
|
|
The Subject's Distinguished Name is as follows
|
|
commonName :ASN.1 12:'monitor-gating.stg'
|
|
Certificate is to be certified until Feb 9 14:52:07 2023 GMT (1080 days)
|
|
failed to update database
|
|
TXT_DB error number 2
|
|
|
|
Easy-RSA error:
|
|
|
|
signing failed (openssl output above may have more detail)
|
|
----
|
|
|
|
This is because you're trying to generate a certificate for a name that already
|
|
exists in the database (as explained in:
|
|
https://zeldor.biz/2013/11/txt_db-error-number-2-failed-to-update-database/
|
|
|
|
The easiest way around this is to simply do a ``git grep <name of your cert>``.
|
|
It should tell you that the name can be found in `index.txt` (and potentially
|
|
`index.txt.old` if another certificate was generated since the first attempt
|
|
and yours).
|
|
|
|
Edit this/these file(s) and remove the line concerning your certificate, then
|
|
re-run the `easyrsa` command as above.
|