Lines Matching +full:layer +full:- +full:depth

9 - enable DANE TLS authentication of the remote TLS server in the local
39 per-connection DANE support as appropriate.
58 By default, matching type C<SHA2-256(1)> (see RFC7218 for definitions
60 with a strength ordinal of C<1> and matching type C<SHA2-512(2)>
65 (The connection must be associated with a DANE-enabled SSL context).
90 and authentication will be based on any configured traditional trust-anchors;
92 DANE-authenticated.
95 the matched DANE trust-anchor after successful connection completion.
98 number indicating the depth at which a TA record matched an issuer certificate.
105 The returned address is a short-term internal reference to the certificate and
108 L<X509_up_ref(3)> to obtain a long-term reference which must then be freed via
112 a DANE-TA(2) SPKI(1) Full(0) record provided the public key that signed an
115 In this case the return value is the depth of the top-most element of the
117 As with B<mcert> this is a short-term internal reference, and
119 release long-term references respectively.
123 The return value indicates the match depth or failure to match just as with
128 The B<data> field is in binary wire form, and is therefore not NUL-terminated,
131 The B<data> parameter is set to a short-term internal-copy of the associated
133 Applications that need long-term access to this field need to copy the content.
139 The B<flags> argument is a bit-mask of the features to enable or disable.
147 DANE-EE(3) TLSA records.
152 The malicious server may then be able to violate cross-origin scripting
155 DANE-EE(3) TLSA records, and can be disabled in applications where it is safe
176 nonnegative value indicates the chain depth at which the TLSA record matched a
177 chain certificate, or the depth of the top-most certificate, when the TLSA
187 DNSSEC-validated TLSA records.
213   * For many applications it is safe to skip DANE-EE(3) namechecks.  Do not
231       * Opportunistic DANE TLS clients support only DANE-TA(2) or DANE-EE(3).
232       * They treat all other certificate usages, and in particular PKIX-TA(0)
233       * and PKIX-EE(1), as unusable.
237      case 0:     /* PKIX-TA(0) */
238      case 1:     /* PKIX-EE(1) */
240      case 2:     /* DANE-TA(2) */
241      case 3:     /* DANE-EE(3) */
264      /* Optionally set verify_cb to a suitable non-NULL callback. */
269      /* Optionally set verify_cb to a suitable non-NULL callback. */
275       * verified disconnect gracefully at the application layer, especially if
306      int depth = SSL_get0_dane_authority(ssl, NULL, &mspki);
307      if (depth >= 0) {
309          printf("DANE TLSA %d %d %d %s at depth %d\n", usage, selector, mtype,
311                 depth ? "matched TA certificate" : "matched EE certificate",
312                 depth);
331 That is, they will use DANE authentication when DNSSEC-validated TLSA records
336 with usages PKIX-TA(0) and PKIX-EE(1) as "unusable", and should not include
376 Copyright 2016-2021 The OpenSSL Project Authors. All Rights Reserved.