Vérifier les certificats du cluster PostgreSQL

Lors de l'installation, lors d'un renouvellement, ou simplement pour connaître la date d'expiration des certificats du cluster PostgreSQL, il peut être utile d'examiner le contenu des certificats générés.

Les certificats utilisés par le cluster PostgreSQL sont les suivants :

/etc/etcd/
├── ca.crt
├── client.crt
├── client.key
├── peer.crt
└── peer.key

/etc/patroni/
├── ca.crt
├── client.crt
└── client.key

ca.crt

Certificat de l'autorité de certification racine. Le même certificat est présent dans les répertoires /etc/patroni/ et /etc/etcd/.

client.crt

Certificat du nœud PostgreSQL. Le même certificat est présent dans les répertoires /etc/patroni/ et /etc/etcd/. Il est utilisé par patroni et etcd pour les communications clientes entre les nœuds.

client.key

Clé associée au certificat client.crt.

peer.crt

Même certificat que client.crt. Il est utilisé pour les communications internes de etcd entre les nœuds.

peer.key

Même clé que client.key.

Il y a donc en tout trois éléments :

• le certificat de l'autorité de certification racine (/etc/etcd/ca.crt, /etc/patroni/ca.crt) ;
• le certificat du nœud PostgreSQL (/etc/etcd/client.crt, /etc/etcd/peer.crt, /etc/patroni/client.crt) ;
• la clé associée au certificat du nœud PostgreSQL (/etc/etcd/client.key, /etc/etcd/peer.key, /etc/patroni/client.key).

Vérifier la date d'expiration d'un certificat

Pour vérifier la date d'expiration d'un certificat, utilisez la commande ci-dessous.

Vous pouvez personnaliser la variable de la commande suivante :

Valeur personnalisée	Variable	Commentaire
	EXPIRY_CERT	Chemin du certificat dont vérifier la date d'expiration.

Ou remplissez le champ avec l'un des certificats du cluster :

/etc/etcd/ca.crt /etc/etcd/client.crt /etc/etcd/peer.crt /etc/patroni/ca.crt /etc/patroni/client.crt

openssl x509 -in EXPIRY_CERT -noout -enddate

Si la date d'expiration est dépassée, le certificat est considéré comme invalide.

Attention

Si l'autorité de certification qui a émis le certificat a expiré, le certificat est lui aussi considéré comme invalide. Vérifiez donc également la date d'expiration de l'autorité de certification.

Exemple

Pour vérifier la date d'expiration du certificat /etc/patroni/client.crt, on utilise la commande suivante :

openssl x509 -in /etc/patroni/client.crt -noout -enddate

Le retour est similaire à celui-ci :

notAfter=Dec 18 14:04:09 2030 GMT

Ici, le certificat expire le 18 décembre 2030 à 14:04:09.

Vérifier les noms alternatifs (SAN) d'un certificat

Pour vérifier les SAN (Subject Alternative Name) d'un certificat, c'est-à-dire les noms et adresses IP pour lesquels il est valide, utilisez la commande ci-dessous.

Vous pouvez personnaliser la variable de la commande suivante :

Valeur personnalisée	Variable	Commentaire
	SAN_CERT	Chemin du certificat dont vérifier les SAN.

Ou remplissez le champ avec l'un des certificats du nœud :

/etc/etcd/client.crt /etc/etcd/peer.crt /etc/patroni/client.crt

openssl x509 -in SAN_CERT -noout -ext subjectAltName

Si le nom DNS ou l'adresse IP utilisé pour se connecter à un nœud ne figure pas dans les SAN de son certificat, la connexion est considérée comme invalide. De même, lorsqu'un nœud ouvre une connexion vers un autre nœud, si le certificat qu'il présente ne correspond pas à son propre nom DNS ou à sa propre adresse IP, le nœud distant rejette la connexion.

Exemple

Pour vérifier les SAN du certificat /etc/etcd/peer.crt, on utilise la commande suivante :

openssl x509 -in /etc/etcd/peer.crt -noout -ext subjectAltName

La commande retourne un résultat similaire à celui-ci :

X509v3 Subject Alternative Name:
    DNS:PSQL_VIP, DNS:PSQL_2, IP Address:192.168.1.4, IP Address:192.168.1.2

Ici, le certificat couvre les noms DNS PSQL_VIP et PSQL_2, ainsi que les adresses IP 192.168.1.4 et 192.168.1.2.

Vérifier quelle autorité de certification a émis un certificat

Lorsqu'un certificat est généré, il est possible de lui ajouter l'extension X509v3 Authority Key Identifier. Cette extension peut stocker le hash de la clé publique de son émetteur, qui correspond au contenu de l'extension X509v3 Subject Key Identifier de l'émetteur.

Info

Les certificats générés en suivant la documentation d'installation du cluster PostgreSQL possèdent les extensions Authority Key Identifier et Subject Key Identifier.

Si ces extensions sont présentes, on peut récupérer le hash de la clé publique de l'émetteur d'un certificat, puis le comparer au hash contenu dans l'extension Subject Key Identifier de l'AC censée avoir émis le certificat, afin de valider qu'il s'agit bien de la bonne.

Pour récupérer la valeur de l'extension Authority Key Identifier d'un certificat, utilisez la commande ci-dessous.

Vous pouvez personnaliser la variable de la commande suivante :

Valeur personnalisée	Variable	Commentaire
	ISSUED_CERT	Chemin du certificat dont vérifier l'émetteur.

Ou remplissez le champ avec l'un des certificats du nœud :

/etc/etcd/client.crt /etc/etcd/peer.crt /etc/patroni/client.crt

openssl x509 -in ISSUED_CERT -noout -issuer -ext authorityKeyIdentifier

Info

L'option -issuer permet de récupérer le CN du certificat émetteur.

Pour récupérer la valeur de l'extension Subject Key Identifier d'un certificat, utilisez la commande ci-dessous.

Vous pouvez personnaliser la variable de la commande suivante :

Valeur personnalisée	Variable	Commentaire
	ISSUER_CA	Chemin du certificat de l'autorité de certification supposée émettrice.

Ou remplissez le champ avec l'un des certificats de l'autorité de certification :

/etc/etcd/ca.crt /etc/patroni/ca.crt

openssl x509 -in ISSUER_CA -noout -subject -ext subjectKeyIdentifier

Info

L'option -subject permet de récupérer le CN du certificat.

Exemple

On souhaite vérifier que l'AC qui a signé le certificat contenu dans le fichier /etc/patroni/client.crt est bien celle contenue dans le fichier /etc/patroni/ca.crt.
On récupère d'abord le contenu de l'extension X509v3 Authority Key Identifier du certificat /etc/patroni/client.crt avec la commande suivante :

openssl x509 -in /etc/patroni/client.crt -noout -issuer -ext authorityKeyIdentifier

Ce qui retourne :

issuer=CN = BDD-ROOT-CA
X509v3 Authority Key Identifier:
    38:B3:EC:CD:20:90:80:A4:B3:60:F8:E5:7B:98:92:3B:7D:26:06:2B

On récupère ensuite le contenu de l'extension X509v3 Subject Key Identifier de l'AC /etc/patroni/ca.crt avec la commande suivante :

openssl x509 -in /etc/patroni/ca.crt -noout -subject -ext subjectKeyIdentifier

Ce qui retourne :

subject=CN = BDD-ROOT-CA
X509v3 Subject Key Identifier:
    38:B3:EC:CD:20:90:80:A4:B3:60:F8:E5:7B:98:92:3B:7D:26:06:2B

En comparant les deux retours, on constate que le Key Identifier et le CN sont identiques : le certificat contenu dans le fichier /etc/patroni/ca.crt est bien l'AC qui a signé le certificat contenu dans le fichier /etc/patroni/client.crt.