xref: /freebsd/crypto/openssl/doc/man1/openssl-verification-options.pod (revision 1719886f6d08408b834d270c59ffcfd821c8f63a)
1=pod
2
3=head1 NAME
4
5openssl-verification-options - generic X.509 certificate verification options
6
7=head1 SYNOPSIS
8
9B<openssl>
10I<command>
11[ I<options> ... ]
12[ I<parameters> ... ]
13
14=head1 DESCRIPTION
15
16There are many situations where X.509 certificates are verified
17within the OpenSSL libraries and in various OpenSSL commands.
18
19Certificate verification is implemented by L<X509_verify_cert(3)>.
20It is a complicated process consisting of a number of steps
21and depending on numerous options.
22The most important of them are detailed in the following sections.
23
24In a nutshell, a valid chain of certificates needs to be built up and verified
25starting from the I<target certificate> that is to be verified
26and ending in a certificate that due to some policy is trusted.
27Verification is done relative to the given I<purpose>, which is the intended use
28of the target certificate, such as SSL server, or by default for any purpose.
29
30The details of how each OpenSSL command handles errors
31are documented on the specific command page.
32
33DANE support is documented in L<openssl-s_client(1)>,
34L<SSL_CTX_dane_enable(3)>, L<SSL_set1_host(3)>,
35L<X509_VERIFY_PARAM_set_flags(3)>, and L<X509_check_host(3)>.
36
37=head2 Trust Anchors
38
39In general, according to RFC 4158 and RFC 5280, a I<trust anchor> is
40any public key and related subject distinguished name (DN) that
41for some reason is considered trusted
42and thus is acceptable as the root of a chain of certificates.
43
44In practice, trust anchors are given in the form of certificates,
45where their essential fields are the public key and the subject DN.
46In addition to the requirements in RFC 5280,
47OpenSSL checks the validity period of such certificates
48and makes use of some further fields.
49In particular, the subject key identifier extension, if present,
50is used for matching trust anchors during chain building.
51
52In the most simple and common case, trust anchors are by default
53all self-signed "root" CA certificates that are placed in the I<trust store>,
54which is a collection of certificates that are trusted for certain uses.
55This is akin to what is used in the trust stores of Mozilla Firefox,
56or Apple's and Microsoft's certificate stores, ...
57
58From the OpenSSL perspective, a trust anchor is a certificate
59that should be augmented with an explicit designation for which
60uses of a target certificate the certificate may serve as a trust anchor.
61In PEM encoding, this is indicated by the C<TRUSTED CERTIFICATE> string.
62Such a designation provides a set of positive trust attributes
63explicitly stating trust for the listed purposes
64and/or a set of negative trust attributes
65explicitly rejecting the use for the listed purposes.
66The purposes are encoded using the values defined for the extended key usages
67(EKUs) that may be given in X.509 extensions of end-entity certificates.
68See also the L</Extended Key Usage> section below.
69
70The currently recognized uses are
71B<clientAuth> (SSL client use), B<serverAuth> (SSL server use),
72B<emailProtection> (S/MIME email use), B<codeSigning> (object signer use),
73B<OCSPSigning> (OCSP responder use), B<OCSP> (OCSP request use),
74B<timeStamping> (TSA server use), and B<anyExtendedKeyUsage>.
75As of OpenSSL 1.1.0, the last of these blocks all uses when rejected or
76enables all uses when trusted.
77
78A certificate, which may be CA certificate or an end-entity certificate,
79is considered a trust anchor for the given use
80if and only if all the following conditions hold:
81
82=over 4
83
84=item *
85
86It is an an element of the trust store.
87
88=item *
89
90It does not have a negative trust attribute rejecting the given use.
91
92=item *
93
94It has a positive trust attribute accepting the given use
95or (by default) one of the following compatibility conditions apply:
96It is self-signed or the B<-partial_chain> option is given
97(which corresponds to the B<X509_V_FLAG_PARTIAL_CHAIN> flag being set).
98
99=back
100
101=head2 Certification Path Building
102
103First, a certificate chain is built up starting from the target certificate
104and ending in a trust anchor.
105
106The chain is built up iteratively, looking up in turn
107a certificate with suitable key usage that
108matches as an issuer of the current "subject" certificate as described below.
109If there is such a certificate, the first one found that is currently valid
110is taken, otherwise the one that expired most recently of all such certificates.
111For efficiency, no backtracking is performed, thus
112any further candidate issuer certificates that would match equally are ignored.
113
114When a self-signed certificate has been added, chain construction stops.
115In this case it must fully match a trust anchor, otherwise chain building fails.
116
117A candidate issuer certificate matches a subject certificate
118if all of the following conditions hold:
119
120=over 4
121
122=item *
123
124Its subject name matches the issuer name of the subject certificate.
125
126=item *
127
128If the subject certificate has an authority key identifier extension,
129each of its sub-fields equals the corresponding subject key identifier, serial
130number, and issuer field of the candidate issuer certificate,
131as far as the respective fields are present in both certificates.
132
133=item *
134
135The certificate signature algorithm used to sign the subject certificate
136is supported and
137equals the public key algorithm of the candidate issuer certificate.
138
139=back
140
141The lookup first searches for issuer certificates in the trust store.
142If it does not find a match there it consults
143the list of untrusted ("intermediate" CA) certificates, if provided.
144
145=head2 Certification Path Validation
146
147When the certificate chain building process was successful
148the chain components and their links are checked thoroughly.
149
150The first step is to check that each certificate is well-formed.
151Part of these checks are enabled only if the B<-x509_strict> option is given.
152
153The second step is to check the extensions of every untrusted certificate
154for consistency with the supplied purpose.
155If the B<-purpose> option is not given then no such checks are done
156except for SSL/TLS connection setup,
157where by default C<sslserver> or C<sslclient>, are checked.
158The target or "leaf" certificate, as well as any other untrusted certificates,
159must have extensions compatible with the specified purpose.
160All certificates except the target or "leaf" must also be valid CA certificates.
161The precise extensions required are described in more detail in
162L<openssl-x509(1)/CERTIFICATE EXTENSIONS>.
163
164The third step is to check the trust settings on the last certificate
165(which typically is a self-signed root CA certificate).
166It must be trusted for the given use.
167For compatibility with previous versions of OpenSSL, a self-signed certificate
168with no trust attributes is considered to be valid for all uses.
169
170The fourth, and final, step is to check the validity of the certificate chain.
171For each element in the chain, including the root CA certificate,
172the validity period as specified by the C<notBefore> and C<notAfter> fields
173is checked against the current system time.
174The B<-attime> flag may be used to use a reference time other than "now."
175The certificate signature is checked as well
176(except for the signature of the typically self-signed root CA certificate,
177which is verified only if the B<-check_ss_sig> option is given).
178When verifying a certificate signature
179the keyUsage extension (if present) of the candidate issuer certificate
180is checked to permit digitalSignature for signing proxy certificates
181or to permit keyCertSign for signing other certificates, respectively.
182If all operations complete successfully then certificate is considered
183valid. If any operation fails then the certificate is not valid.
184
185=head1 OPTIONS
186
187=head2 Trusted Certificate Options
188
189The following options specify how to supply the certificates
190that can be used as trust anchors for certain uses.
191As mentioned, a collection of such certificates is called a I<trust store>.
192
193Note that OpenSSL does not provide a default set of trust anchors.  Many
194Linux distributions include a system default and configure OpenSSL to point
195to that.  Mozilla maintains an influential trust store that can be found at
196L<https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/>.
197
198The certificates to add to the trust store
199can be specified using following options.
200
201=over 4
202
203=item B<-CAfile> I<file>
204
205Load the specified file which contains a certificate
206or several of them in case the input is in PEM or PKCS#12 format.
207PEM-encoded certificates may also have trust attributes set.
208
209=item B<-no-CAfile>
210
211Do not load the default file of trusted certificates.
212
213=item B<-CApath> I<dir>
214
215Use the specified directory as a collection of trusted certificates,
216i.e., a trust store.
217Files should be named with the hash value of the X.509 SubjectName of each
218certificate. This is so that the library can extract the IssuerName,
219hash it, and directly lookup the file to get the issuer certificate.
220See L<openssl-rehash(1)> for information on creating this type of directory.
221
222=item B<-no-CApath>
223
224Do not use the default directory of trusted certificates.
225
226=item B<-CAstore> I<uri>
227
228Use I<uri> as a store of CA certificates.
229The URI may indicate a single certificate, as well as a collection of them.
230With URIs in the C<file:> scheme, this acts as B<-CAfile> or
231B<-CApath>, depending on if the URI indicates a single file or
232directory.
233See L<ossl_store-file(7)> for more information on the C<file:> scheme.
234
235These certificates are also used when building the server certificate
236chain (for example with L<openssl-s_server(1)>) or client certificate
237chain (for example with L<openssl-s_time(1)>).
238
239=item B<-no-CAstore>
240
241Do not use the default store of trusted CA certificates.
242
243=back
244
245=head2 Verification Options
246
247The certificate verification can be fine-tuned with the following flags.
248
249=over 4
250
251=item B<-verbose>
252
253Print extra information about the operations being performed.
254
255=item B<-attime> I<timestamp>
256
257Perform validation checks using time specified by I<timestamp> and not
258current system time. I<timestamp> is the number of seconds since
259January 1, 1970 (i.e., the Unix Epoch).
260
261=item B<-no_check_time>
262
263This option suppresses checking the validity period of certificates and CRLs
264against the current time. If option B<-attime> is used to specify
265a verification time, the check is not suppressed.
266
267=item B<-x509_strict>
268
269This disables non-compliant workarounds for broken certificates.
270Thus errors are thrown on certificates not compliant with RFC 5280.
271
272When this option is set,
273among others, the following certificate well-formedness conditions are checked:
274
275=over 4
276
277=item *
278
279The basicConstraints of CA certificates must be marked critical.
280
281=item *
282
283CA certificates must explicitly include the keyUsage extension.
284
285=item *
286
287If a pathlenConstraint is given the key usage keyCertSign must be allowed.
288
289=item *
290
291The pathlenConstraint must not be given for non-CA certificates.
292
293=item *
294
295The issuer name of any certificate must not be empty.
296
297=item *
298
299The subject name of CA certs, certs with keyUsage crlSign, and certs
300without subjectAlternativeName must not be empty.
301
302=item *
303
304If a subjectAlternativeName extension is given it must not be empty.
305
306=item *
307
308The signatureAlgorithm field and the cert signature must be consistent.
309
310=item *
311
312Any given authorityKeyIdentifier and any given subjectKeyIdentifier
313must not be marked critical.
314
315=item *
316
317The authorityKeyIdentifier must be given for X.509v3 certs unless they
318are self-signed.
319
320=item *
321
322The subjectKeyIdentifier must be given for all X.509v3 CA certs.
323
324=back
325
326=item B<-ignore_critical>
327
328Normally if an unhandled critical extension is present that is not
329supported by OpenSSL the certificate is rejected (as required by RFC5280).
330If this option is set critical extensions are ignored.
331
332=item B<-issuer_checks>
333
334Ignored.
335
336=item B<-crl_check>
337
338Checks end entity certificate validity by attempting to look up a valid CRL.
339If a valid CRL cannot be found an error occurs.
340
341=item B<-crl_check_all>
342
343Checks the validity of B<all> certificates in the chain by attempting
344to look up valid CRLs.
345
346=item B<-use_deltas>
347
348Enable support for delta CRLs.
349
350=item B<-extended_crl>
351
352Enable extended CRL features such as indirect CRLs and alternate CRL
353signing keys.
354
355=item B<-suiteB_128_only>, B<-suiteB_128>, B<-suiteB_192>
356
357Enable the Suite B mode operation at 128 bit Level of Security, 128 bit or
358192 bit, or only 192 bit Level of Security respectively.
359See RFC6460 for details. In particular the supported signature algorithms are
360reduced to support only ECDSA and SHA256 or SHA384 and only the elliptic curves
361P-256 and P-384.
362
363=item B<-auth_level> I<level>
364
365Set the certificate chain authentication security level to I<level>.
366The authentication security level determines the acceptable signature and
367public key strength when verifying certificate chains.  For a certificate
368chain to validate, the public keys of all the certificates must meet the
369specified security I<level>.  The signature algorithm security level is
370enforced for all the certificates in the chain except for the chain's
371I<trust anchor>, which is either directly trusted or validated by means
372other than its signature.  See L<SSL_CTX_set_security_level(3)> for the
373definitions of the available levels.  The default security level is -1,
374or "not set".  At security level 0 or lower all algorithms are acceptable.
375Security level 1 requires at least 80-bit-equivalent security and is broadly
376interoperable, though it will, for example, reject MD5 signatures or RSA
377keys shorter than 1024 bits.
378
379=item B<-partial_chain>
380
381Allow verification to succeed if an incomplete chain can be built.
382That is, a chain ending in a certificate that normally would not be trusted
383(because it has no matching positive trust attributes and is not self-signed)
384but is an element of the trust store.
385This certificate may be self-issued or belong to an intermediate CA.
386
387=item B<-check_ss_sig>
388
389Verify the signature of
390the last certificate in a chain if the certificate is supposedly self-signed.
391This is prohibited and will result in an error if it is a non-conforming CA
392certificate with key usage restrictions not including the keyCertSign bit.
393This verification is disabled by default because it doesn't add any security.
394
395=item B<-allow_proxy_certs>
396
397Allow the verification of proxy certificates.
398
399=item B<-trusted_first>
400
401As of OpenSSL 1.1.0 this option is on by default and cannot be disabled.
402
403When constructing the certificate chain, the trusted certificates specified
404via B<-CAfile>, B<-CApath>, B<-CAstore> or B<-trusted> are always used
405before any certificates specified via B<-untrusted>.
406
407=item B<-no_alt_chains>
408
409As of OpenSSL 1.1.0, since B<-trusted_first> always on, this option has no
410effect.
411
412=item B<-trusted> I<file>
413
414Parse I<file> as a set of one or more certificates.
415Each of them qualifies as trusted if has a suitable positive trust attribute
416or it is self-signed or the B<-partial_chain> option is specified.
417This option implies the B<-no-CAfile>, B<-no-CApath>, and B<-no-CAstore> options
418and it cannot be used with the B<-CAfile>, B<-CApath> or B<-CAstore> options, so
419only certificates specified using the B<-trusted> option are trust anchors.
420This option may be used multiple times.
421
422=item B<-untrusted> I<file>
423
424Parse I<file> as a set of one or more certificates.
425All certificates (typically of intermediate CAs) are considered untrusted
426and may be used to
427construct a certificate chain from the target certificate to a trust anchor.
428This option may be used multiple times.
429
430=item B<-policy> I<arg>
431
432Enable policy processing and add I<arg> to the user-initial-policy-set (see
433RFC5280). The policy I<arg> can be an object name an OID in numeric form.
434This argument can appear more than once.
435
436=item B<-explicit_policy>
437
438Set policy variable require-explicit-policy (see RFC5280).
439
440=item B<-policy_check>
441
442Enables certificate policy processing.
443
444=item B<-policy_print>
445
446Print out diagnostics related to policy processing.
447
448=item B<-inhibit_any>
449
450Set policy variable inhibit-any-policy (see RFC5280).
451
452=item B<-inhibit_map>
453
454Set policy variable inhibit-policy-mapping (see RFC5280).
455
456=item B<-purpose> I<purpose>
457
458The intended use for the certificate.
459Currently defined purposes are C<sslclient>, C<sslserver>, C<nssslserver>,
460C<smimesign>, C<smimeencrypt>, C<crlsign>, C<ocsphelper>, C<timestampsign>,
461and C<any>.
462If peer certificate verification is enabled, by default the TLS implementation
463as well as the commands B<s_client> and B<s_server> check for consistency
464with TLS server or TLS client use, respectively.
465
466While IETF RFC 5280 says that B<id-kp-serverAuth> and B<id-kp-clientAuth>
467are only for WWW use, in practice they are used for all kinds of TLS clients
468and servers, and this is what OpenSSL assumes as well.
469
470=item B<-verify_depth> I<num>
471
472Limit the certificate chain to I<num> intermediate CA certificates.
473A maximal depth chain can have up to I<num>+2 certificates, since neither the
474end-entity certificate nor the trust-anchor certificate count against the
475B<-verify_depth> limit.
476
477=item B<-verify_email> I<email>
478
479Verify if I<email> matches the email address in Subject Alternative Name or
480the email in the subject Distinguished Name.
481
482=item B<-verify_hostname> I<hostname>
483
484Verify if I<hostname> matches DNS name in Subject Alternative Name or
485Common Name in the subject certificate.
486
487=item B<-verify_ip> I<ip>
488
489Verify if I<ip> matches the IP address in Subject Alternative Name of
490the subject certificate.
491
492=item B<-verify_name> I<name>
493
494Use default verification policies like trust model and required certificate
495policies identified by I<name>.
496The trust model determines which auxiliary trust or reject OIDs are applicable
497to verifying the given certificate chain.
498They can be given using the B<-addtrust> and B<-addreject> options
499for L<openssl-x509(1)>.
500Supported policy names include: B<default>, B<pkcs7>, B<smime_sign>,
501B<ssl_client>, B<ssl_server>.
502These mimics the combinations of purpose and trust settings used in SSL, CMS
503and S/MIME.
504As of OpenSSL 1.1.0, the trust model is inferred from the purpose when not
505specified, so the B<-verify_name> options are functionally equivalent to the
506corresponding B<-purpose> settings.
507
508=back
509
510=head2 Extended Verification Options
511
512Sometimes there may be more than one certificate chain leading to an
513end-entity certificate.
514This usually happens when a root or intermediate CA signs a certificate
515for another a CA in other organization.
516Another reason is when a CA might have intermediates that use two different
517signature formats, such as a SHA-1 and a SHA-256 digest.
518
519The following options can be used to provide data that will allow the
520OpenSSL command to generate an alternative chain.
521
522=over 4
523
524=item B<-xkey> I<infile>, B<-xcert> I<infile>, B<-xchain>
525
526Specify an extra certificate, private key and certificate chain. These behave
527in the same manner as the B<-cert>, B<-key> and B<-cert_chain> options.  When
528specified, the callback returning the first valid chain will be in use by the
529client.
530
531=item B<-xchain_build>
532
533Specify whether the application should build the certificate chain to be
534provided to the server for the extra certificates via the B<-xkey>,
535B<-xcert>, and B<-xchain> options.
536
537=item B<-xcertform> B<DER>|B<PEM>|B<P12>
538
539The input format for the extra certificate.
540This option has no effect and is retained for backward compatibility only.
541
542=item B<-xkeyform> B<DER>|B<PEM>|B<P12>
543
544The input format for the extra key.
545This option has no effect and is retained for backward compatibility only.
546
547=back
548
549=head2 Certificate Extensions
550
551Options like B<-purpose> lead to checking the certificate extensions,
552which determine what the target certificate and intermediate CA certificates
553can be used for.
554
555=head3 Basic Constraints
556
557The basicConstraints extension CA flag is used to determine whether the
558certificate can be used as a CA. If the CA flag is true then it is a CA,
559if the CA flag is false then it is not a CA. B<All> CAs should have the
560CA flag set to true.
561
562If the basicConstraints extension is absent,
563which includes the case that it is an X.509v1 certificate,
564then the certificate is considered to be a "possible CA" and
565other extensions are checked according to the intended use of the certificate.
566The treatment of certificates without basicConstraints as a CA
567is presently supported, but this could change in the future.
568
569=head3 Key Usage
570
571If the keyUsage extension is present then additional restraints are
572made on the uses of the certificate. A CA certificate B<must> have the
573keyCertSign bit set if the keyUsage extension is present.
574
575=head3 Extended Key Usage
576
577The extKeyUsage (EKU) extension places additional restrictions on the
578certificate uses. If this extension is present (whether critical or not)
579the key can only be used for the purposes specified.
580
581A complete description of each check is given below. The comments about
582basicConstraints and keyUsage and X.509v1 certificates above apply to B<all>
583CA certificates.
584
585
586=over 4
587
588=item B<SSL Client>
589
590The extended key usage extension must be absent or include the "web client
591authentication" OID.  The keyUsage extension must be absent or it must have the
592digitalSignature bit set.  The Netscape certificate type must be absent
593or it must have the SSL client bit set.
594
595=item B<SSL Client CA>
596
597The extended key usage extension must be absent or include the "web client
598authentication" OID.
599The Netscape certificate type must be absent or it must have the SSL CA bit set.
600This is used as a work around if the basicConstraints extension is absent.
601
602=item B<SSL Server>
603
604The extended key usage extension must be absent or include the "web server
605authentication" and/or one of the SGC OIDs.  The keyUsage extension must be
606absent or it
607must have the digitalSignature, the keyEncipherment set or both bits set.
608The Netscape certificate type must be absent or have the SSL server bit set.
609
610=item B<SSL Server CA>
611
612The extended key usage extension must be absent or include the "web server
613authentication" and/or one of the SGC OIDs.  The Netscape certificate type must
614be absent or the SSL CA bit must be set.
615This is used as a work around if the basicConstraints extension is absent.
616
617=item B<Netscape SSL Server>
618
619For Netscape SSL clients to connect to an SSL server it must have the
620keyEncipherment bit set if the keyUsage extension is present. This isn't
621always valid because some cipher suites use the key for digital signing.
622Otherwise it is the same as a normal SSL server.
623
624=item B<Common S/MIME Client Tests>
625
626The extended key usage extension must be absent or include the "email
627protection" OID.  The Netscape certificate type must be absent or should have the
628S/MIME bit set. If the S/MIME bit is not set in the Netscape certificate type
629then the SSL client bit is tolerated as an alternative but a warning is shown.
630This is because some Verisign certificates don't set the S/MIME bit.
631
632=item B<S/MIME Signing>
633
634In addition to the common S/MIME client tests the digitalSignature bit or
635the nonRepudiation bit must be set if the keyUsage extension is present.
636
637=item B<S/MIME Encryption>
638
639In addition to the common S/MIME tests the keyEncipherment bit must be set
640if the keyUsage extension is present.
641
642=item B<S/MIME CA>
643
644The extended key usage extension must be absent or include the "email
645protection" OID.  The Netscape certificate type must be absent or must have the
646S/MIME CA bit set.
647This is used as a work around if the basicConstraints extension is absent.
648
649=item B<CRL Signing>
650
651The keyUsage extension must be absent or it must have the CRL signing bit
652set.
653
654=item B<CRL Signing CA>
655
656The normal CA tests apply. Except in this case the basicConstraints extension
657must be present.
658
659=back
660
661=head1 BUGS
662
663The issuer checks still suffer from limitations in the underlying X509_LOOKUP
664API.  One consequence of this is that trusted certificates with matching
665subject name must appear in a file (as specified by the B<-CAfile> option),
666a directory (as specified by B<-CApath>),
667or a store (as specified by B<-CAstore>).
668If there are multiple such matches, possibly in multiple locations,
669only the first one (in the mentioned order of locations) is recognised.
670
671=head1 SEE ALSO
672
673L<X509_verify_cert(3)>,
674L<openssl-verify(1)>,
675L<openssl-ocsp(1)>,
676L<openssl-ts(1)>,
677L<openssl-s_client(1)>,
678L<openssl-s_server(1)>,
679L<openssl-smime(1)>,
680L<openssl-cmp(1)>,
681L<openssl-cms(1)>
682
683=head1 HISTORY
684
685The checks enabled by B<-x509_strict> have been extended in OpenSSL 3.0.
686
687=head1 COPYRIGHT
688
689Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved.
690
691Licensed under the Apache License 2.0 (the "License").  You may not use
692this file except in compliance with the License.  You can obtain a copy
693in the file LICENSE in the source distribution or at
694L<https://www.openssl.org/source/license.html>.
695
696=cut
697