summaryrefslogtreecommitdiffstats
path: root/doc/src/sgml/sslinfo.sgml
blob: 85d49f66537cf03dec6801f8ff16500bfc4bd9b0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
<!-- doc/src/sgml/sslinfo.sgml -->

<sect1 id="sslinfo" xreflabel="sslinfo">
 <title>sslinfo &mdash; obtain client SSL information</title>

 <indexterm zone="sslinfo">
  <primary>sslinfo</primary>
 </indexterm>

 <para>
  The <filename>sslinfo</filename> module provides information about the SSL
  certificate that the current client provided when connecting to
  <productname>PostgreSQL</productname>.  The module is useless (most functions
  will return NULL) if the current connection does not use SSL.
 </para>

 <para>
  Some of the information available through this module can also be obtained
  using the built-in system view <link linkend="monitoring-pg-stat-ssl-view">
  <structname>pg_stat_ssl</structname></link>.
 </para>

 <para>
  This extension won't build at all unless the installation was
  configured with <literal>--with-ssl=openssl</literal>.
 </para>

 <sect2 id="sslinfo-functions">
  <title>Functions Provided</title>

  <variablelist>
   <varlistentry>
    <term>
     <function>ssl_is_used() returns boolean</function>
     <indexterm>
      <primary>ssl_is_used</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     Returns true if current connection to server uses SSL, and false
     otherwise.
    </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>
     <function>ssl_version() returns text</function>
     <indexterm>
      <primary>ssl_version</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     Returns the name of the protocol used for the SSL connection (e.g., TLSv1.0,
     TLSv1.1, TLSv1.2 or TLSv1.3).
    </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>
     <function>ssl_cipher() returns text</function>
     <indexterm>
      <primary>ssl_cipher</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     Returns the name of the cipher used for the SSL connection
     (e.g., DHE-RSA-AES256-SHA).
    </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>
     <function>ssl_client_cert_present() returns boolean</function>
     <indexterm>
      <primary>ssl_client_cert_present</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     Returns true if current client has presented a valid SSL client
     certificate to the server, and false otherwise.  (The server
     might or might not be configured to require a client certificate.)
    </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>
     <function>ssl_client_serial() returns numeric</function>
     <indexterm>
      <primary>ssl_client_serial</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     Returns serial number of current client certificate.  The combination of
     certificate serial number and certificate issuer is guaranteed to
     uniquely identify a certificate (but not its owner &mdash; the owner
     ought to regularly change their keys, and get new certificates from the
     issuer).
    </para>

    <para>
     So, if you run your own CA and allow only certificates from this CA to
     be accepted by the server, the serial number is the most reliable (albeit
     not very mnemonic) means to identify a user.
    </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>
     <function>ssl_client_dn() returns text</function>
     <indexterm>
      <primary>ssl_client_dn</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     Returns the full subject of the current client certificate, converting
     character data into the current database encoding.  It is assumed that
     if you use non-ASCII characters in the certificate names, your
     database is able to represent these characters, too.  If your database
     uses the SQL_ASCII encoding, non-ASCII characters in the name will be
     represented as UTF-8 sequences.
    </para>

    <para>
     The result looks like <literal>/CN=Somebody /C=Some country/O=Some organization</literal>.
    </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>
     <function>ssl_issuer_dn() returns text</function>
     <indexterm>
      <primary>ssl_issuer_dn</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     Returns the full issuer name of the current client certificate, converting
     character data into the current database encoding.  Encoding conversions
     are handled the same as for <function>ssl_client_dn</function>.
    </para>
    <para>
     The combination of the return value of this function with the
     certificate serial number uniquely identifies the certificate.
    </para>
    <para>
     This function is really useful only if you have more than one trusted CA
     certificate in your server's certificate authority file, or if this CA
     has issued some intermediate certificate authority certificates.
    </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>
     <function>ssl_client_dn_field(fieldname text) returns text</function>
     <indexterm>
      <primary>ssl_client_dn_field</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     This function returns the value of the specified field in the
     certificate subject, or NULL if the field is not present.
     Field names are string constants that are converted into ASN1 object
     identifiers using the <productname>OpenSSL</productname> object
     database.  The following values are acceptable:
    </para>
<literallayout class="monospaced">
commonName (alias CN)
surname (alias SN)
name
givenName (alias GN)
countryName (alias C)
localityName (alias L)
stateOrProvinceName (alias ST)
organizationName (alias O)
organizationalUnitName (alias OU)
title
description
initials
postalCode
streetAddress
generationQualifier
description
dnQualifier
x500UniqueIdentifier
pseudonym
role
emailAddress
</literallayout>
    <para>
     All of these fields are optional, except <structfield>commonName</structfield>.
     It depends
     entirely on your CA's policy which of them would be included and which
     wouldn't.  The meaning of these fields, however, is strictly defined by
     the X.500 and X.509 standards, so you cannot just assign arbitrary
     meaning to them.
    </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>
     <function>ssl_issuer_field(fieldname text) returns text</function>
     <indexterm>
      <primary>ssl_issuer_field</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     Same as <function>ssl_client_dn_field</function>, but for the certificate issuer
     rather than the certificate subject.
    </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>
     <function>ssl_extension_info() returns setof record</function>
     <indexterm>
      <primary>ssl_extension_info</primary>
     </indexterm>
    </term>
    <listitem>
    <para>
     Provide information about extensions of client certificate: extension name,
     extension value, and if it is a critical extension.
    </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </sect2>

 <sect2 id="sslinfo-author">
  <title>Author</title>

  <para>
   Victor Wagner <email>vitus@cryptocom.ru</email>, Cryptocom LTD
  </para>

  <para>
   Dmitry Voronin <email>carriingfate92@yandex.ru</email>
  </para>

  <para>
   E-Mail of Cryptocom OpenSSL development group:
   <email>openssl@cryptocom.ru</email>
  </para>
 </sect2>

</sect1>