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