diff options
| author | Peter Eisentraut <peter@eisentraut.org> | 2022-04-01 15:41:44 +0200 |
|---|---|---|
| committer | Peter Eisentraut <peter@eisentraut.org> | 2022-04-01 15:51:23 +0200 |
| commit | c1932e542863f0f646f005b3492452acc57c7e66 (patch) | |
| tree | 5b5b5235d68749d804f8fdf0cb7d47a7fd3fd032 /doc/src | |
| parent | fa25bebb827a8cc4d62f15d564b0093f40b9d44d (diff) | |
libpq: Allow IP address SANs in server certificates
The current implementation supports exactly one IP address in a server
certificate's Common Name, which is brittle (the strings must match
exactly). This patch adds support for IPv4 and IPv6 addresses in a
server's Subject Alternative Names.
Per discussion on-list:
- If the client's expected host is an IP address, we allow fallback to
the Subject Common Name if an iPAddress SAN is not present, even if
a dNSName is present. This matches the behavior of NSS, in
violation of the relevant RFCs.
- We also, counter-intuitively, match IP addresses embedded in dNSName
SANs. From inspection this appears to have been the behavior since
the SAN matching feature was introduced in acd08d76.
- Unlike NSS, we don't map IPv4 to IPv6 addresses, or vice-versa.
Author: Jacob Champion <pchampion@vmware.com>
Co-authored-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Co-authored-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://www.postgresql.org/message-id/flat/9f5f20974cd3a4091a788cf7f00ab663d5fcdffe.camel@vmware.com
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/libpq.sgml | 21 |
1 files changed, 18 insertions, 3 deletions
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 0b2a8720f04..1c20901c3c1 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -8356,16 +8356,31 @@ ldap://ldap.acme.com/cn=dbserver,cn=hosts?pgconnectinfo?base?(objectclass=*) <para> In <literal>verify-full</literal> mode, the host name is matched against the - certificate's Subject Alternative Name attribute(s), or against the - Common Name attribute if no Subject Alternative Name of type <literal>dNSName</literal> is + certificate's Subject Alternative Name attribute(s) (SAN), or against the + Common Name attribute if no SAN of type <literal>dNSName</literal> is present. If the certificate's name attribute starts with an asterisk (<literal>*</literal>), the asterisk will be treated as a wildcard, which will match all characters <emphasis>except</emphasis> a dot (<literal>.</literal>). This means the certificate will not match subdomains. If the connection is made using an IP address instead of a host name, the - IP address will be matched (without doing any DNS lookups). + IP address will be matched (without doing any DNS lookups) against SANs of + type <literal>iPAddress</literal> or <literal>dNSName</literal>. If no + <literal>iPAddress</literal> SAN is present and no + matching <literal>dNSName</literal> SAN is present, the host IP address is + matched against the Common Name attribute. </para> + <note> + <para> + For backward compatibility with earlier versions of PostgreSQL, the host + IP address is verified in a manner different + from <ulink url="https://tools.ietf.org/html/rfc6125">RFC 6125</ulink>. + The host IP address is always matched against <literal>dNSName</literal> + SANs as well as <literal>iPAddress</literal> SANs, and can be matched + against the Common Name attribute if no relevant SANs exist. + </para> + </note> + <para> To allow server certificate verification, one or more root certificates must be placed in the file <filename>~/.postgresql/root.crt</filename> |