2021-10-19 20:11:42 +02:00
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
#
|
|
|
|
# Makefile for sslfiles
|
|
|
|
#
|
|
|
|
# The SSL test files are completely disjoint from the rest of the build; they
|
|
|
|
# don't rely on other targets or on Makefile.global. Since these recipes rely
|
|
|
|
# on some default Make behavior that's disabled in the main build tree, such
|
|
|
|
# as intermediate cleanup, they've been moved into their own separate file.
|
|
|
|
# The main Makefile in this directory defers to this helper file when
|
|
|
|
# building the sslfiles-related targets.
|
|
|
|
#
|
2023-01-02 21:00:37 +01:00
|
|
|
# Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2021-10-19 20:11:42 +02:00
|
|
|
# Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
#
|
|
|
|
# src/test/ssl/sslfiles.mk
|
|
|
|
#
|
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
|
|
|
#
|
|
|
|
# To add a new server or client certificate, add a new <name>.config file in
|
|
|
|
# the conf/ directory, then add <name> to either SERVERS or CLIENTS below. A
|
|
|
|
# key/certificate pair will be generated for you, signed by the appropriate CA.
|
|
|
|
#
|
|
|
|
SERVERS := server-cn-and-alt-names \
|
2022-04-01 15:41:44 +02:00
|
|
|
server-cn-and-ip-alt-names \
|
2021-10-19 20:11:42 +02:00
|
|
|
server-cn-only \
|
2022-04-01 15:41:44 +02:00
|
|
|
server-ip-alt-names \
|
2022-04-01 14:06:23 +02:00
|
|
|
server-ip-cn-only \
|
2022-04-01 15:41:44 +02:00
|
|
|
server-ip-cn-and-alt-names \
|
|
|
|
server-ip-cn-and-dns-alt-names \
|
2022-04-01 14:06:23 +02:00
|
|
|
server-ip-in-dnsname \
|
2021-10-19 20:11:42 +02:00
|
|
|
server-single-alt-name \
|
|
|
|
server-multiple-alt-names \
|
|
|
|
server-no-names \
|
|
|
|
server-revoked
|
2022-09-13 16:10:50 +02:00
|
|
|
CLIENTS := client client-dn client-revoked client_ext client-long \
|
|
|
|
client-revoked-utf8
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
#
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
# To add a new non-standard certificate, add it to SPECIAL_CERTS and then add
|
|
|
|
# a recipe for creating it to the "Special-case certificates" section below.
|
2021-10-19 20:11:42 +02:00
|
|
|
#
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
SPECIAL_CERTS := ssl/server-rsapss.crt
|
|
|
|
|
|
|
|
# Likewise for non-standard keys
|
2021-10-19 20:11:42 +02:00
|
|
|
SPECIAL_KEYS := ssl/server-password.key \
|
|
|
|
ssl/client-der.key \
|
|
|
|
ssl/client-encrypted-pem.key \
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
ssl/client-encrypted-der.key \
|
|
|
|
ssl/server-rsapss.key
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# These files are just concatenations of other files. You can add new ones to
|
|
|
|
# COMBINATIONS here, then declare the constituent files as dependencies in the
|
|
|
|
# "Combined files" section below.
|
|
|
|
#
|
|
|
|
COMBINATIONS := \
|
|
|
|
ssl/both-cas-1.crt \
|
|
|
|
ssl/both-cas-2.crt \
|
|
|
|
ssl/root+server_ca.crt \
|
|
|
|
ssl/root+server.crl \
|
|
|
|
ssl/root+client_ca.crt \
|
|
|
|
ssl/root+client.crl \
|
2023-04-05 23:22:17 +02:00
|
|
|
ssl/client+client_ca.crt \
|
|
|
|
ssl/server-cn-only+server_ca.crt
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
CERTIFICATES := root_ca server_ca client_ca $(SERVERS) $(CLIENTS)
|
|
|
|
STANDARD_CERTS := $(CERTIFICATES:%=ssl/%.crt)
|
|
|
|
STANDARD_KEYS := $(CERTIFICATES:%=ssl/%.key)
|
|
|
|
CRLS := ssl/root.crl \
|
|
|
|
ssl/client.crl \
|
|
|
|
ssl/server.crl
|
|
|
|
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
SSLFILES := \
|
|
|
|
$(STANDARD_CERTS) \
|
|
|
|
$(STANDARD_KEYS) \
|
|
|
|
$(SPECIAL_CERTS) \
|
|
|
|
$(SPECIAL_KEYS) \
|
|
|
|
$(COMBINATIONS) \
|
|
|
|
$(CRLS)
|
2021-10-19 20:11:42 +02:00
|
|
|
SSLDIRS := ssl/client-crldir \
|
|
|
|
ssl/server-crldir \
|
|
|
|
ssl/root+client-crldir \
|
|
|
|
ssl/root+server-crldir
|
|
|
|
|
|
|
|
# This target re-generates all the key and certificate files. Usually we just
|
|
|
|
# use the ones that are committed to the tree without rebuilding them.
|
|
|
|
#
|
|
|
|
.PHONY: sslfiles
|
|
|
|
sslfiles: $(SSLFILES) $(SSLDIRS)
|
|
|
|
|
|
|
|
#
|
|
|
|
# Special-case certificates
|
|
|
|
#
|
|
|
|
|
|
|
|
# Root CA is self-signed.
|
|
|
|
ssl/root_ca.crt: ssl/root_ca.key conf/root_ca.config
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) req -new -x509 -config conf/root_ca.config -days 10000 -key $< -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
# Certificate using RSA-PSS algorithm. Also self-signed.
|
|
|
|
ssl/server-rsapss.crt: ssl/server-rsapss.key conf/server-rsapss.config
|
|
|
|
$(OPENSSL) req -new -x509 -config conf/server-rsapss.config -key $< -out $@
|
|
|
|
|
2021-10-19 20:11:42 +02:00
|
|
|
#
|
|
|
|
# Special-case keys
|
|
|
|
#
|
|
|
|
# All targets here are contained in $(SPECIAL_KEYS).
|
|
|
|
#
|
|
|
|
|
|
|
|
# Password-protected version of server-cn-only.key
|
|
|
|
ssl/server-password.key: ssl/server-cn-only.key
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) rsa -aes256 -in $< -out $@ -passout 'pass:secret1'
|
2021-10-19 20:11:42 +02:00
|
|
|
|
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 02:12:16 +01:00
|
|
|
# Key that uses the RSA-PSS algorithm
|
|
|
|
ssl/server-rsapss.key:
|
|
|
|
$(OPENSSL) genpkey -algorithm rsa-pss -out $@
|
|
|
|
|
2021-10-19 20:11:42 +02:00
|
|
|
# DER-encoded version of client.key
|
|
|
|
ssl/client-der.key: ssl/client.key
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) rsa -in $< -outform DER -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
# Convert client.key to encrypted PEM (X.509 text) and DER (X.509 ASN.1)
|
|
|
|
# formats to test libpq's support for the sslpassword= option.
|
|
|
|
ssl/client-encrypted-pem.key: ssl/client.key
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) rsa -in $< -outform PEM -aes128 -passout 'pass:dUmmyP^#+' -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
# TODO Explicitly choosing -aes128 generates a key unusable to PostgreSQL with
|
|
|
|
# OpenSSL 3.0.0, so fall back on the default for now.
|
|
|
|
ssl/client-encrypted-der.key: ssl/client.key
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) rsa -in $< -outform DER -passout 'pass:dUmmyP^#+' -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# Combined files
|
|
|
|
#
|
|
|
|
# All targets in $(COMBINATIONS) share a single recipe; just declare the
|
|
|
|
# necessary dependencies and they'll be smashed together.
|
|
|
|
#
|
|
|
|
|
|
|
|
# Root certificate file that contains both CA certificates, for testing
|
|
|
|
# that multiple certificates can be used.
|
|
|
|
ssl/both-cas-1.crt: ssl/root_ca.crt ssl/client_ca.crt ssl/server_ca.crt
|
|
|
|
|
|
|
|
# The same, but the certs are in different order
|
|
|
|
ssl/both-cas-2.crt: ssl/root_ca.crt ssl/server_ca.crt ssl/client_ca.crt
|
|
|
|
|
|
|
|
# A root certificate file for the client, to validate server certs.
|
|
|
|
ssl/root+server_ca.crt: ssl/root_ca.crt ssl/server_ca.crt
|
|
|
|
|
|
|
|
# and for the server, to validate client certs
|
|
|
|
ssl/root+client_ca.crt: ssl/root_ca.crt ssl/client_ca.crt
|
|
|
|
|
|
|
|
# and for the client, to present to the server
|
|
|
|
ssl/client+client_ca.crt: ssl/client.crt ssl/client_ca.crt
|
|
|
|
|
2023-04-05 23:22:17 +02:00
|
|
|
# for the server, to present to a client that only knows the root
|
|
|
|
ssl/server-cn-only+server_ca.crt: ssl/server-cn-only.crt ssl/server_ca.crt
|
|
|
|
|
2021-10-19 20:11:42 +02:00
|
|
|
# If a CRL is used, OpenSSL requires a CRL file for *all* the CAs in the
|
|
|
|
# chain, even if some of them are empty.
|
|
|
|
ssl/root+server.crl: ssl/root.crl ssl/server.crl
|
|
|
|
ssl/root+client.crl: ssl/root.crl ssl/client.crl
|
|
|
|
|
|
|
|
$(COMBINATIONS):
|
|
|
|
cat $^ > $@
|
|
|
|
|
|
|
|
#
|
|
|
|
# Standard keys
|
|
|
|
#
|
|
|
|
|
|
|
|
$(STANDARD_KEYS):
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) genrsa -out $@ 2048
|
2021-10-19 20:11:42 +02:00
|
|
|
chmod 0600 $@
|
|
|
|
|
|
|
|
#
|
|
|
|
# Standard certificates
|
|
|
|
#
|
|
|
|
|
|
|
|
CA_CERTS := ssl/server_ca.crt ssl/client_ca.crt
|
|
|
|
SERVER_CERTS := $(SERVERS:%=ssl/%.crt)
|
|
|
|
CLIENT_CERTS := $(CLIENTS:%=ssl/%.crt)
|
|
|
|
|
|
|
|
# See the "CA State" section below.
|
|
|
|
root_ca_state_files := ssl/root_ca-certindex ssl/root_ca-certindex.attr ssl/root_ca.srl
|
|
|
|
server_ca_state_files := ssl/server_ca-certindex ssl/server_ca-certindex.attr ssl/server_ca.srl
|
|
|
|
client_ca_state_files := ssl/client_ca-certindex ssl/client_ca-certindex.attr ssl/client_ca.srl
|
|
|
|
|
|
|
|
# These are the workhorse recipes. `openssl ca` can't be safely run from
|
|
|
|
# parallel processes, so we must mark the entire Makefile .NOTPARALLEL.
|
|
|
|
.NOTPARALLEL:
|
|
|
|
$(CA_CERTS): ssl/%.crt: ssl/%.csr conf/%.config conf/cas.config ssl/root_ca.crt | ssl/new_certs_dir $(root_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -batch -config conf/cas.config -name root_ca -notext -in $< -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
$(SERVER_CERTS): ssl/%.crt: ssl/%.csr conf/%.config conf/cas.config ssl/server_ca.crt | ssl/new_certs_dir $(server_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -batch -config conf/cas.config -name server_ca -notext -in $< -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
$(CLIENT_CERTS): ssl/%.crt: ssl/%.csr conf/%.config conf/cas.config ssl/client_ca.crt | ssl/new_certs_dir $(client_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -batch -config conf/cas.config -name client_ca -notext -in $< -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
# The CSRs don't need to persist after a build.
|
|
|
|
.INTERMEDIATE: $(CERTIFICATES:%=ssl/%.csr)
|
|
|
|
ssl/%.csr: ssl/%.key conf/%.config
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) req -new -utf8 -key $< -out $@ -config conf/$*.config
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# CA State
|
|
|
|
#
|
|
|
|
# All of these are intended to be order-only dependencies; additionally, the
|
|
|
|
# pattern recipes are marked as explicit intermediates. The goal is for Make to
|
|
|
|
# create the state files once for each CA, allow them to accumulate whatever
|
|
|
|
# state is needed, and then automatically remove them at the end of the run.
|
|
|
|
#
|
|
|
|
|
|
|
|
.INTERMEDIATE: $(root_ca_state_files) $(server_ca_state_files) $(client_ca_state_files)
|
|
|
|
|
|
|
|
# OpenSSL requires a directory to put all generated certificates in. We don't
|
|
|
|
# use this for anything, but we need a location.
|
|
|
|
ssl/new_certs_dir:
|
|
|
|
mkdir $@
|
|
|
|
|
|
|
|
ssl/%-certindex:
|
|
|
|
touch $@
|
|
|
|
|
|
|
|
ssl/%-certindex.attr:
|
|
|
|
echo "unique_subject=no" > $@
|
|
|
|
|
|
|
|
# The first serial number for each CA is based on the current timestamp, to
|
|
|
|
# avoid collisions across Make runs.
|
|
|
|
ssl/%.srl:
|
|
|
|
date +%Y%m%d%H%M%S00 > $@
|
|
|
|
|
|
|
|
#
|
|
|
|
# CRLs
|
|
|
|
#
|
|
|
|
|
|
|
|
ssl/root.crl: ssl/root_ca.crt | $(root_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -config conf/cas.config -name root_ca -gencrl -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
ssl/server.crl: ssl/server-revoked.crt ssl/server_ca.crt | $(server_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -config conf/cas.config -name server_ca -revoke $<
|
|
|
|
$(OPENSSL) ca -config conf/cas.config -name server_ca -gencrl -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
2022-09-13 16:10:50 +02:00
|
|
|
ssl/client.crl: ssl/client-revoked.crt ssl/client-revoked-utf8.crt ssl/client_ca.crt | $(client_ca_state_files)
|
2022-10-20 21:01:05 +02:00
|
|
|
$(OPENSSL) ca -config conf/cas.config -name client_ca -revoke ssl/client-revoked.crt
|
|
|
|
$(OPENSSL) ca -config conf/cas.config -name client_ca -revoke ssl/client-revoked-utf8.crt
|
|
|
|
$(OPENSSL) ca -config conf/cas.config -name client_ca -gencrl -out $@
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# CRL hash directories
|
|
|
|
#
|
|
|
|
|
|
|
|
ssl/root+server-crldir: ssl/server.crl ssl/root.crl
|
|
|
|
ssl/root+client-crldir: ssl/client.crl ssl/root.crl
|
|
|
|
ssl/server-crldir: ssl/server.crl
|
|
|
|
ssl/client-crldir: ssl/client.crl
|
|
|
|
|
2022-10-20 21:01:05 +02:00
|
|
|
crlhashfile = $(shell $(OPENSSL) crl -hash -noout -in $(1)).r0
|
2021-10-19 20:11:42 +02:00
|
|
|
|
|
|
|
ssl/%-crldir:
|
|
|
|
mkdir -p $@
|
|
|
|
rm -f $@/*.r0
|
|
|
|
$(foreach crl,$^,cp $(crl) $@/$(call crlhashfile,$(crl)) &&) true
|
|
|
|
touch $@
|
|
|
|
|
|
|
|
.PHONY: sslfiles-clean
|
|
|
|
sslfiles-clean:
|
|
|
|
rm -f $(SSLFILES) ssl/*.old ssl/*.csr ssl/*.srl ssl/*-certindex*
|
|
|
|
rm -rf $(SSLDIRS) ssl/new_certs_dir
|
|
|
|
|
|
|
|
# The difference between the below clean targets and sslfiles-clean is that the
|
|
|
|
# clean targets will be run during a "standard" recursive clean run from the
|
|
|
|
# main build tree. The sslfiles-clean target must be run explicitly from this
|
|
|
|
# directory.
|
|
|
|
.PHONY: clean distclean maintainer-clean
|
|
|
|
clean distclean maintainer-clean:
|
|
|
|
rm -rf ssl/*.old ssl/new_certs_dir ssl/client*_tmp.key
|