]>
Commit | Line | Data |
---|---|---|
553615f5 RL |
1 | =pod |
2 | ||
3 | =head1 NAME | |
4 | ||
9e183d22 | 5 | SSL_get_ex_data_X509_STORE_CTX_idx, |
121677b4 RS |
6 | SSL_CTX_set_verify, SSL_set_verify, |
7 | SSL_CTX_set_verify_depth, SSL_set_verify_depth, | |
9d75dce3 TS |
8 | SSL_verify_cb, |
9 | SSL_verify_client_post_handshake, | |
e97be718 MC |
10 | SSL_set_post_handshake_auth, |
11 | SSL_CTX_set_post_handshake_auth | |
4acda863 | 12 | - set various SSL/TLS parameters for peer certificate verification |
553615f5 RL |
13 | |
14 | =head1 SYNOPSIS | |
15 | ||
16 | #include <openssl/ssl.h> | |
17 | ||
89a01e69 BB |
18 | typedef int (*SSL_verify_cb)(int preverify_ok, X509_STORE_CTX *x509_ctx); |
19 | ||
3adc41dd | 20 | void SSL_CTX_set_verify(SSL_CTX *ctx, int mode, SSL_verify_cb verify_callback); |
9d75dce3 | 21 | void SSL_set_verify(SSL *ssl, int mode, SSL_verify_cb verify_callback); |
9e183d22 RS |
22 | SSL_get_ex_data_X509_STORE_CTX_idx(void); |
23 | ||
aebb9aac | 24 | void SSL_CTX_set_verify_depth(SSL_CTX *ctx, int depth); |
9d75dce3 TS |
25 | void SSL_set_verify_depth(SSL *ssl, int depth); |
26 | ||
27 | int SSL_verify_client_post_handshake(SSL *ssl); | |
e97be718 | 28 | void SSL_CTX_set_post_handshake_auth(SSL_CTX *ctx, int val); |
32097b33 | 29 | void SSL_set_post_handshake_auth(SSL *ssl, int val); |
553615f5 | 30 | |
553615f5 RL |
31 | =head1 DESCRIPTION |
32 | ||
33 | SSL_CTX_set_verify() sets the verification flags for B<ctx> to be B<mode> and | |
34 | specifies the B<verify_callback> function to be used. If no callback function | |
35 | shall be specified, the NULL pointer can be used for B<verify_callback>. | |
36 | ||
37 | SSL_set_verify() sets the verification flags for B<ssl> to be B<mode> and | |
38 | specifies the B<verify_callback> function to be used. If no callback function | |
39 | shall be specified, the NULL pointer can be used for B<verify_callback>. In | |
40 | this case last B<verify_callback> set specifically for this B<ssl> remains. If | |
41 | no special B<callback> was set before, the default callback for the underlying | |
477fd459 | 42 | B<ctx> is used, that was valid at the time B<ssl> was created with |
9e183d22 RS |
43 | L<SSL_new(3)>. Within the callback function, |
44 | B<SSL_get_ex_data_X509_STORE_CTX_idx> can be called to get the data index | |
45 | of the current SSL object that is doing the verification. | |
553615f5 | 46 | |
dfb39f73 TM |
47 | In client mode B<verify_callback> may also call the L<SSL_set_retry_verify(3)> |
48 | function on the B<SSL> object set in the I<x509_store_ctx> ex data (see | |
49 | L<SSL_get_ex_data_X509_STORE_CTX_idx(3)>) and return 1. | |
50 | This would be typically done in case the certificate verification was not yet | |
51 | able to succeed. | |
52 | This makes the handshake suspend and return control to the calling application | |
53 | with B<SSL_ERROR_WANT_RETRY_VERIFY>. | |
54 | The application can for instance fetch further certificates or cert status | |
55 | information needed for the verification. | |
dfb39f73 TM |
56 | Calling L<SSL_connect(3)> again resumes the connection attempt by retrying the |
57 | server certificate verification step. | |
58 | This process may even be repeated if need be. | |
1aa1bba5 DDO |
59 | Note that the handshake may still be aborted if a subsequent invocation of the |
60 | callback (e.g., at a lower depth, or for a separate error condition) returns 0. | |
dfb39f73 | 61 | |
553615f5 | 62 | SSL_CTX_set_verify_depth() sets the maximum B<depth> for the certificate chain |
800b5dac | 63 | verification that shall be allowed for B<ctx>. |
553615f5 RL |
64 | |
65 | SSL_set_verify_depth() sets the maximum B<depth> for the certificate chain | |
800b5dac | 66 | verification that shall be allowed for B<ssl>. |
553615f5 | 67 | |
e97be718 MC |
68 | SSL_CTX_set_post_handshake_auth() and SSL_set_post_handshake_auth() enable the |
69 | Post-Handshake Authentication extension to be added to the ClientHello such that | |
70 | post-handshake authentication can be requested by the server. If B<val> is 0 | |
71 | then the extension is not sent, otherwise it is. By default the extension is not | |
72 | sent. A certificate callback will need to be set via | |
73 | SSL_CTX_set_client_cert_cb() if no certificate is provided at initialization. | |
9d75dce3 | 74 | |
658e4879 | 75 | SSL_verify_client_post_handshake() causes a CertificateRequest message to be |
9d75dce3 | 76 | sent by a server on the given B<ssl> connection. The SSL_VERIFY_PEER flag must |
658e4879 | 77 | be set; the SSL_VERIFY_POST_HANDSHAKE flag is optional. |
9d75dce3 | 78 | |
553615f5 RL |
79 | =head1 NOTES |
80 | ||
81 | The verification of certificates can be controlled by a set of logically | |
82 | or'ed B<mode> flags: | |
83 | ||
84 | =over 4 | |
85 | ||
86 | =item SSL_VERIFY_NONE | |
87 | ||
88 | B<Server mode:> the server will not send a client certificate request to the | |
89 | client, so the client will not send a certificate. | |
90 | ||
91 | B<Client mode:> if not using an anonymous cipher (by default disabled), the | |
92 | server will send a certificate which will be checked. The result of the | |
93 | certificate verification process can be checked after the TLS/SSL handshake | |
9b86974e | 94 | using the L<SSL_get_verify_result(3)> function. |
553615f5 RL |
95 | The handshake will be continued regardless of the verification result. |
96 | ||
97 | =item SSL_VERIFY_PEER | |
98 | ||
99 | B<Server mode:> the server sends a client certificate request to the client. | |
100 | The certificate returned (if any) is checked. If the verification process | |
c4068186 | 101 | fails, the TLS/SSL handshake is |
553615f5 RL |
102 | immediately terminated with an alert message containing the reason for |
103 | the verification failure. | |
104 | The behaviour can be controlled by the additional | |
9d75dce3 TS |
105 | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, SSL_VERIFY_CLIENT_ONCE and |
106 | SSL_VERIFY_POST_HANDSHAKE flags. | |
553615f5 RL |
107 | |
108 | B<Client mode:> the server certificate is verified. If the verification process | |
c4068186 | 109 | fails, the TLS/SSL handshake is |
553615f5 RL |
110 | immediately terminated with an alert message containing the reason for |
111 | the verification failure. If no server certificate is sent, because an | |
112 | anonymous cipher is used, SSL_VERIFY_PEER is ignored. | |
113 | ||
114 | =item SSL_VERIFY_FAIL_IF_NO_PEER_CERT | |
115 | ||
116 | B<Server mode:> if the client did not return a certificate, the TLS/SSL | |
117 | handshake is immediately terminated with a "handshake failure" alert. | |
118 | This flag must be used together with SSL_VERIFY_PEER. | |
119 | ||
e6716f2b | 120 | B<Client mode:> ignored (see BUGS) |
553615f5 RL |
121 | |
122 | =item SSL_VERIFY_CLIENT_ONCE | |
123 | ||
9d75dce3 TS |
124 | B<Server mode:> only request a client certificate once during the |
125 | connection. Do not ask for a client certificate again during | |
126 | renegotiation or post-authentication if a certificate was requested | |
127 | during the initial handshake. This flag must be used together with | |
128 | SSL_VERIFY_PEER. | |
129 | ||
e6716f2b | 130 | B<Client mode:> ignored (see BUGS) |
9d75dce3 TS |
131 | |
132 | =item SSL_VERIFY_POST_HANDSHAKE | |
133 | ||
134 | B<Server mode:> the server will not send a client certificate request | |
135 | during the initial handshake, but will send the request via | |
136 | SSL_verify_client_post_handshake(). This allows the SSL_CTX or SSL | |
137 | to be configured for post-handshake peer verification before the | |
138 | handshake occurs. This flag must be used together with | |
139 | SSL_VERIFY_PEER. TLSv1.3 only; no effect on pre-TLSv1.3 connections. | |
553615f5 | 140 | |
e6716f2b | 141 | B<Client mode:> ignored (see BUGS) |
553615f5 RL |
142 | |
143 | =back | |
144 | ||
c636c1c4 | 145 | If the B<mode> is SSL_VERIFY_NONE none of the other flags may be set. |
553615f5 | 146 | |
a73e07db RB |
147 | If verification flags are not modified explicitly by C<SSL_CTX_set_verify()> |
148 | or C<SSL_set_verify()>, the default value will be SSL_VERIFY_NONE. | |
149 | ||
c4068186 LJ |
150 | The actual verification procedure is performed either using the built-in |
151 | verification procedure or using another application provided verification | |
152 | function set with | |
9b86974e | 153 | L<SSL_CTX_set_cert_verify_callback(3)>. |
c4068186 LJ |
154 | The following descriptions apply in the case of the built-in procedure. An |
155 | application provided procedure also has access to the verify depth information | |
156 | and the verify_callback() function, but the way this information is used | |
157 | may be different. | |
158 | ||
800b5dac TA |
159 | SSL_CTX_set_verify_depth() and SSL_set_verify_depth() set a limit on the |
160 | number of certificates between the end-entity and trust-anchor certificates. | |
161 | Neither the | |
162 | end-entity nor the trust-anchor certificates count against B<depth>. If the | |
163 | certificate chain needed to reach a trusted issuer is longer than B<depth+2>, | |
164 | X509_V_ERR_CERT_CHAIN_TOO_LONG will be issued. | |
553615f5 RL |
165 | The depth count is "level 0:peer certificate", "level 1: CA certificate", |
166 | "level 2: higher level CA certificate", and so on. Setting the maximum | |
800b5dac TA |
167 | depth to 2 allows the levels 0, 1, 2 and 3 (0 being the end-entity and 3 the |
168 | trust-anchor). | |
169 | The default depth limit is 100, | |
170 | allowing for the peer certificate, at most 100 intermediate CA certificates and | |
171 | a final trust anchor certificate. | |
553615f5 RL |
172 | |
173 | The B<verify_callback> function is used to control the behaviour when the | |
174 | SSL_VERIFY_PEER flag is set. It must be supplied by the application and | |
175 | receives two arguments: B<preverify_ok> indicates, whether the verification of | |
176 | the certificate in question was passed (preverify_ok=1) or not | |
177 | (preverify_ok=0). B<x509_ctx> is a pointer to the complete context used | |
178 | for the certificate chain verification. | |
179 | ||
180 | The certificate chain is checked starting with the deepest nesting level | |
181 | (the root CA certificate) and worked upward to the peer's certificate. | |
182 | At each level signatures and issuer attributes are checked. Whenever | |
183 | a verification error is found, the error number is stored in B<x509_ctx> | |
184 | and B<verify_callback> is called with B<preverify_ok>=0. By applying | |
185 | X509_CTX_store_* functions B<verify_callback> can locate the certificate | |
186 | in question and perform additional steps (see EXAMPLES). If no error is | |
187 | found for a certificate, B<verify_callback> is called with B<preverify_ok>=1 | |
188 | before advancing to the next level. | |
189 | ||
190 | The return value of B<verify_callback> controls the strategy of the further | |
191 | verification process. If B<verify_callback> returns 0, the verification | |
192 | process is immediately stopped with "verification failed" state. If | |
193 | SSL_VERIFY_PEER is set, a verification failure alert is sent to the peer and | |
194 | the TLS/SSL handshake is terminated. If B<verify_callback> returns 1, | |
195 | the verification process is continued. If B<verify_callback> always returns | |
9d19fbc4 LJ |
196 | 1, the TLS/SSL handshake will not be terminated with respect to verification |
197 | failures and the connection will be established. The calling process can | |
198 | however retrieve the error code of the last verification error using | |
9b86974e | 199 | L<SSL_get_verify_result(3)> or by maintaining its |
553615f5 RL |
200 | own error storage managed by B<verify_callback>. |
201 | ||
202 | If no B<verify_callback> is specified, the default callback will be used. | |
203 | Its return value is identical to B<preverify_ok>, so that any verification | |
204 | failure will lead to a termination of the TLS/SSL handshake with an | |
205 | alert message, if SSL_VERIFY_PEER is set. | |
206 | ||
77890553 | 207 | After calling SSL_set_post_handshake_auth(), the client will need to add a |
658e4879 TS |
208 | certificate or certificate callback to its configuration before it can |
209 | successfully authenticate. This must be called before SSL_connect(). | |
9d75dce3 TS |
210 | |
211 | SSL_verify_client_post_handshake() requires that verify flags have been | |
212 | previously set, and that a client sent the post-handshake authentication | |
213 | extension. When the client returns a certificate the verify callback will be | |
214 | invoked. A write operation must take place for the Certificate Request to be | |
215 | sent to the client, this can be done with SSL_do_handshake() or SSL_write_ex(). | |
216 | Only one certificate request may be outstanding at any time. | |
217 | ||
658e4879 | 218 | When post-handshake authentication occurs, a refreshed NewSessionTicket |
9d75dce3 TS |
219 | message is sent to the client. |
220 | ||
7163617f | 221 | Post-handshake authentication cannot be used with QUIC. |
d6e7ebba | 222 | SSL_set_post_handshake_auth() has no effect if called on a QUIC SSL object. |
7163617f | 223 | |
c8e2f98c MC |
224 | =head1 BUGS |
225 | ||
226 | In client mode, it is not checked whether the SSL_VERIFY_PEER flag | |
e6716f2b TM |
227 | is set, but whether any flags other than SSL_VERIFY_NONE are set. This can |
228 | lead to unexpected behaviour if SSL_VERIFY_PEER and other flags are not used as | |
c8e2f98c MC |
229 | required. |
230 | ||
553615f5 RL |
231 | =head1 RETURN VALUES |
232 | ||
233 | The SSL*_set_verify*() functions do not provide diagnostic information. | |
234 | ||
9d75dce3 TS |
235 | The SSL_verify_client_post_handshake() function returns 1 if the request |
236 | succeeded, and 0 if the request failed. The error stack can be examined | |
237 | to determine the failure reason. | |
238 | ||
553615f5 RL |
239 | =head1 EXAMPLES |
240 | ||
241 | The following code sequence realizes an example B<verify_callback> function | |
242 | that will always continue the TLS/SSL handshake regardless of verification | |
243 | failure, if wished. The callback realizes a verification depth limit with | |
244 | more informational output. | |
245 | ||
2b4ffc65 SS |
246 | All verification errors are printed; information about the certificate chain |
247 | is printed on request. | |
553615f5 RL |
248 | The example is realized for a server that does allow but not require client |
249 | certificates. | |
250 | ||
b5a6f0a9 LJ |
251 | The example makes use of the ex_data technique to store application data |
252 | into/retrieve application data from the SSL structure | |
9e183d22 | 253 | (see L<CRYPTO_get_ex_new_index(3)>, |
9b86974e | 254 | L<SSL_get_ex_data_X509_STORE_CTX_idx(3)>). |
b5a6f0a9 | 255 | |
553615f5 | 256 | ... |
b5a6f0a9 LJ |
257 | typedef struct { |
258 | int verbose_mode; | |
259 | int verify_depth; | |
260 | int always_continue; | |
261 | } mydata_t; | |
262 | int mydata_index; | |
2947af32 | 263 | |
553615f5 RL |
264 | ... |
265 | static int verify_callback(int preverify_ok, X509_STORE_CTX *ctx) | |
266 | { | |
2947af32 BB |
267 | char buf[256]; |
268 | X509 *err_cert; | |
269 | int err, depth; | |
270 | SSL *ssl; | |
271 | mydata_t *mydata; | |
272 | ||
273 | err_cert = X509_STORE_CTX_get_current_cert(ctx); | |
274 | err = X509_STORE_CTX_get_error(ctx); | |
275 | depth = X509_STORE_CTX_get_error_depth(ctx); | |
276 | ||
277 | /* | |
278 | * Retrieve the pointer to the SSL of the connection currently treated | |
279 | * and the application specific data stored into the SSL object. | |
280 | */ | |
281 | ssl = X509_STORE_CTX_get_ex_data(ctx, SSL_get_ex_data_X509_STORE_CTX_idx()); | |
282 | mydata = SSL_get_ex_data(ssl, mydata_index); | |
283 | ||
284 | X509_NAME_oneline(X509_get_subject_name(err_cert), buf, 256); | |
285 | ||
286 | /* | |
287 | * Catch a too long certificate chain. The depth limit set using | |
288 | * SSL_CTX_set_verify_depth() is by purpose set to "limit+1" so | |
289 | * that whenever the "depth>verify_depth" condition is met, we | |
290 | * have violated the limit and want to log this error condition. | |
291 | * We must do it here, because the CHAIN_TOO_LONG error would not | |
292 | * be found explicitly; only errors introduced by cutting off the | |
293 | * additional certificates would be logged. | |
294 | */ | |
295 | if (depth > mydata->verify_depth) { | |
296 | preverify_ok = 0; | |
297 | err = X509_V_ERR_CERT_CHAIN_TOO_LONG; | |
298 | X509_STORE_CTX_set_error(ctx, err); | |
299 | } | |
300 | if (!preverify_ok) { | |
301 | printf("verify error:num=%d:%s:depth=%d:%s\n", err, | |
302 | X509_verify_cert_error_string(err), depth, buf); | |
303 | } else if (mydata->verbose_mode) { | |
304 | printf("depth=%d:%s\n", depth, buf); | |
305 | } | |
306 | ||
307 | /* | |
308 | * At this point, err contains the last verification error. We can use | |
309 | * it for something special | |
310 | */ | |
311 | if (!preverify_ok && (err == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT)) { | |
312 | X509_NAME_oneline(X509_get_issuer_name(err_cert), buf, 256); | |
313 | printf("issuer= %s\n", buf); | |
314 | } | |
315 | ||
316 | if (mydata->always_continue) | |
317 | return 1; | |
318 | else | |
319 | return preverify_ok; | |
553615f5 | 320 | } |
b5a6f0a9 LJ |
321 | ... |
322 | ||
323 | mydata_t mydata; | |
324 | ||
325 | ... | |
326 | mydata_index = SSL_get_ex_new_index(0, "mydata index", NULL, NULL, NULL); | |
327 | ||
553615f5 | 328 | ... |
2947af32 | 329 | SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE, |
553615f5 RL |
330 | verify_callback); |
331 | ||
332 | /* | |
333 | * Let the verify_callback catch the verify_depth error so that we get | |
334 | * an appropriate error in the logfile. | |
335 | */ | |
336 | SSL_CTX_set_verify_depth(verify_depth + 1); | |
b5a6f0a9 LJ |
337 | |
338 | /* | |
339 | * Set up the SSL specific data into "mydata" and store it into th SSL | |
340 | * structure. | |
341 | */ | |
342 | mydata.verify_depth = verify_depth; ... | |
343 | SSL_set_ex_data(ssl, mydata_index, &mydata); | |
dccd20d1 | 344 | |
553615f5 | 345 | ... |
1bc74519 | 346 | SSL_accept(ssl); /* check of success left out for clarity */ |
2947af32 BB |
347 | if (peer = SSL_get_peer_certificate(ssl)) { |
348 | if (SSL_get_verify_result(ssl) == X509_V_OK) { | |
349 | /* The client sent a certificate which verified OK */ | |
350 | } | |
553615f5 RL |
351 | } |
352 | ||
353 | =head1 SEE ALSO | |
354 | ||
b97fdb57 | 355 | L<ssl(7)>, L<SSL_new(3)>, |
9b86974e RS |
356 | L<SSL_CTX_get_verify_mode(3)>, |
357 | L<SSL_get_verify_result(3)>, | |
358 | L<SSL_CTX_load_verify_locations(3)>, | |
359 | L<SSL_get_peer_certificate(3)>, | |
360 | L<SSL_CTX_set_cert_verify_callback(3)>, | |
361 | L<SSL_get_ex_data_X509_STORE_CTX_idx(3)>, | |
9d75dce3 | 362 | L<SSL_CTX_set_client_cert_cb(3)>, |
9e183d22 | 363 | L<CRYPTO_get_ex_new_index(3)> |
553615f5 | 364 | |
9d75dce3 TS |
365 | =head1 HISTORY |
366 | ||
367 | The SSL_VERIFY_POST_HANDSHAKE option, and the SSL_verify_client_post_handshake() | |
32097b33 | 368 | and SSL_set_post_handshake_auth() functions were added in OpenSSL 1.1.1. |
9d75dce3 | 369 | |
e2f92610 RS |
370 | =head1 COPYRIGHT |
371 | ||
da1c088f | 372 | Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved. |
e2f92610 | 373 | |
4746f25a | 374 | Licensed under the Apache License 2.0 (the "License"). You may not use |
e2f92610 RS |
375 | this file except in compliance with the License. You can obtain a copy |
376 | in the file LICENSE in the source distribution or at | |
377 | L<https://www.openssl.org/source/license.html>. | |
378 | ||
379 | =cut |