Nœuds : certificat / PKI

Authentification par certificat client X.509, dans le cadre d’un graphe d’authentification.

1 2

CertificateCollectorNode : collecte le certificat client X.509. Il prend celui de la connexion TLS avec TOSIAM quand TOSIAM termine lui-même le mTLS ; sinon il lit le certificat (PEM) déposé dans un en-tête HTTP par un reverse proxy qui termine le mTLS, à condition que ce proxy figure dans ses proxys de confiance.

Outcomes : present / absent.

La propriété trustedProxies est disponible à partir de la version 3.38.0. Voir Origine du certificat.

CertificateValidationNode : construit le chemin de certification du certificat client vers une autorité de confiance, le valide (PKIX), puis résout l’identité (par défaut via le SAN e-mail) vers un uid LDAP.

Outcomes : valid / invalid / revoked.

Origine du certificat#

Un certificat est une donnée publique : le présenter ne prouve rien, seule la possession de sa clé privée authentifie. Cette preuve est faite pendant la négociation TLS, par celui qui la termine. CertificateCollectorNode prend donc le certificat à l’un de ces deux endroits, dans cet ordre :

1. La connexion TLS avec TOSIAM. Quand le serveur d’application termine lui-même le TLS mutuel, le nœud prend le certificat de la connexion. Aucun en-tête n’est lu, aucune propriété n’est à renseigner. Il en va de même du certificat que le serveur a déjà accepté d’un proxy de confiance déclaré au niveau du serveur (image de conteneur : TOSIAM_CLIENT_CERT_HEADER et TOSIAM_CLIENT_CERT_PROXIES) : le nœud le reçoit comme celui de la connexion.
2. L’en-tête HTTP d’un proxy de confiance. Quand un proxy inverse termine le TLS mutuel, il transmet le certificat dans l’en-tête headerName. Le nœud ne lit cet en-tête que si la connexion vient d’une adresse de trustedProxies (« Proxys de confiance »).

trustedProxies est une liste d’adresses IP ou de blocs CIDR, IPv4 ou IPv6, séparés par des virgules :

"collect-cert": {
  "type": "CertificateCollectorNode",
  "config": {
    "headerName": "",
    "trustedProxies": "10.0.1.15, 10.0.2.0/24"
  },
  "outcomes": { "present": "validate-cert", "absent": "failure" }
}

Liste vide, la valeur par défaut : l’en-tête n’est jamais lu. Si l’en-tête arrive d’une adresse qui n’est pas dans la liste, il est ignoré, le nœud part vers absent et un avertissement est écrit au journal, avec l’adresse de l’appelant. Une entrée illisible (nom d’hôte, masque invalide) est ignorée, avec un avertissement : elle ne désigne personne.

L’adresse comparée est celle de la machine qui a ouvert la connexion avec TOSIAM, c’est-à-dire le dernier proxy de la chaîne, et non l’adresse annoncée par X-Forwarded-For. Avec l’image de conteneur TOSIAM, et avec tout Tomcat où la valve ForwardedClientCertificateValve (JAR tosiam-tomcat-valves du kit) est déclarée avant la RemoteIpValve, c’est le cas même quand la RemoteIpValve remplace l’adresse du client. Sans cette valve, et sous JBoss / WildFly, l’adresse comparée est celle que rapporte le serveur d’application : si celui-ci la remplace par l’adresse annoncée par X-Forwarded-For (RemoteIpValve, proxy-address-forwarding), le proxy n’est pas reconnu et l’en-tête est ignoré.

Autorités de confiance et intermédiaires#

Les propriétés trustedCertificates, intermediateCertificates, revocationEndEntityOnly et ocspResponderUrl sont disponibles à partir de la version 3.38.0.

Les deux propriétés PEM acceptent plusieurs certificats à la suite, chacun entre -----BEGIN CERTIFICATE----- et -----END CERTIFICATE----- ; les retours à la ligne sont indifférents.

Cas courant d’une racine hors ligne et d’une autorité intermédiaire qui émet les certificats des utilisateurs : déclarer la racine dans trustedCertificates et l’intermédiaire dans intermediateCertificates.

"validate-cert": {
  "type": "CertificateValidationNode",
  "config": {
    "trustedCertificates": "-----BEGIN CERTIFICATE-----\nMIID...racine...\n-----END CERTIFICATE-----",
    "intermediateCertificates": "-----BEGIN CERTIFICATE-----\nMIID...intermédiaire...\n-----END CERTIFICATE-----",
    "checkCrl": true
  },
  "outcomes": { "valid": "success", "invalid": "failure", "revoked": "failure" }
}

Le certificat part vers invalid dans les cas suivants :

• aucun chemin ne le relie à une autorité de confiance, par exemple quand l’intermédiaire qui l’a émis n’est pas déclarée. Le journal nomme le sujet et l’émetteur du certificat refusé ;
• une propriété PEM est renseignée mais ne contient aucun certificat lisible : il n’y a pas de repli sur le truststore de la JVM ;
• le certificat présenté est lui-même une autorité de confiance : un certificat d’autorité est public, le présenter ne prouve rien.

Usage du certificat#

À partir de la version 3.38.0, le nœud refuse (invalid) un certificat émis pour un autre usage que l’authentification d’un client, selon la règle qu’applique un serveur TLS au certificat de son client :

Une extension absente ne restreint rien : un certificat sans extendedKeyUsage ni keyUsage reste accepté. Un certificat de serveur ou de signature de code émis par une autorité de confiance du nœud est refusé, et le journal en donne la raison.

Révocation#

La révocation est réglée pour la seule validation en cours : le nœud ne lit ni n’écrit aucune propriété de sécurité de la JVM, et deux nœuds réglés différemment ne s’influencent pas.

Un certificat révoqué part vers revoked. Un certificat dont l’état ne peut pas être déterminé (service injoignable, certificat sans point de distribution ni répondeur) part vers invalid : il n’y a pas d’échec toléré.

Adresse du répondeur OCSP. Par défaut, TOSIAM interroge le répondeur que chaque certificat déclare (extension authorityInfoAccess) ; un certificat qui n’en déclare pas ne peut alors pas être contrôlé par OCSP. La propriété ocspResponderUrl (« Adresse du répondeur OCSP ») désigne le répondeur à interroger à la place de celui des certificats, pour tous les certificats du chemin. Elle ne s’applique que si checkOcsp est activé ; une adresse illisible envoie le certificat vers invalid. La réponse doit être signée par l’autorité qui a émis le certificat, ou par un répondeur que cette autorité a délégué.

Par défaut, la révocation est vérifiée pour le certificat client et pour les autorités intermédiaires du chemin. Si une intermédiaire ne publie ni CRL ni OCSP, tous les certificats qu’elle émet sont refusés : activer alors revocationEndEntityOnly.

Association au compte#

Le nœud cherche le compte dont l’attribut mail porte l’adresse du certificat. À partir de la version 3.38.0, si plusieurs comptes portent cette adresse, aucun n’est retenu : le certificat part vers invalid, avec un avertissement au journal. Auparavant, l’un des comptes était ouvert, sans règle de choix.