mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-11-21 01:15:20 +08:00
Code Issues Packages Projects Releases Wiki Activity
master
openssl/test/danetest.in

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2008 lines
94 KiB
Plaintext
Raw Permalink Normal View History

Add final(?) set of copyrights. Add copyright to missing assembler files. Add copyrights to missing test/* files. Add copyrights Various source and misc files. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-06-01 23:26:40 +08:00
# Copyright 2016-2016 The OpenSSL Project Authors. All Rights Reserved.
#
Following the license change, modify the boilerplates in test/ Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7767)
2018-12-06 20:05:25 +08:00
# Licensed under the Apache License 2.0 (the "License"). You may not use
Add final(?) set of copyrights. Add copyright to missing assembler files. Add copyrights to missing test/* files. Add copyrights Various source and misc files. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-06-01 23:26:40 +08:00
# this file except in compliance with the License. You can obtain a copy
# in the file LICENSE in the source distribution or at
# https://www.openssl.org/source/license.html
#
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
# Blank and comment lines ignored.
Add final(?) set of copyrights. Add copyright to missing assembler files. Add copyrights to missing test/* files. Add copyrights Various source and misc files. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-06-01 23:26:40 +08:00
#
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
# The first line in each block takes the form:
#
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
# <TLSA-count> <cert-count> <nonamechecks> <desired-verify-result> <desired-match-depth>
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
#
# It is followed by <TLSA-count> lines of the form:
#
# <usage> <selector> <mtype> <hex-data>
#
# and finally, by <cert-count> certificates.
# Test chain matching TLSA records
# --
# subject= CN = example.com
# 3 0 0 308201943082013BA003020102020102300A06082A8648CE3D04030230143112301006035504030C094973737565722043413020170D3135313231333233323335325A180F33303135303431353233323335325A30163114301206035504030C0B6578616D706C652E636F6D3059301306072A8648CE3D020106082A8648CE3D03010703420004664995F47BDE35E7B4DE48B258E9E8A07ADEBBDB863B3D06F481A1946C83DA9F56CFF4D9389B855D2F364B1585B0C734FCFA263026964FF5A4308B3FC879BDB8A37A3078301D0603551D0E041604145B20CA417D9088C7A4C017CB6C0C1C739BB07D8A301F0603551D230418301680147AB75A3CD295CA5DF7C5150916E18FF5CC376A1530090603551D130402300030130603551D25040C300A06082B0601050507030130160603551D11040F300D820B6578616D706C652E636F6D300A06082A8648CE3D0403020347003044021F21C9032A5C8A93872D3F4AEF321A9574DD956D43BD93C369944C72D6902858022100C8B3290D7AF37E571A84D704DBAD339D2987D41852DC5936F212947063911181
# 3 0 1 BEDC04764CECAE80AEE454D332758F50847DCA424216466E4012E0DEAE1F2E5F
# 3 0 2 F756CCD61F3CA50D017653911701CA0052AF0B29E273DD263DD23643D86D4369D03686BD1369EF54BB2DC2DAE3CE4F05AF39D54648F94D54AA86B259AEAD9923
# 3 1 0 3059301306072A8648CE3D020106082A8648CE3D03010703420004664995F47BDE35E7B4DE48B258E9E8A07ADEBBDB863B3D06F481A1946C83DA9F56CFF4D9389B855D2F364B1585B0C734FCFA263026964FF5A4308B3FC879BDB8
# 3 1 1 3111668338043DE264D0256A702248696C9484B6221A42740F920187B4C61838
# 3 1 2 CB861AF6DDED185EE04472A9092052CCC735120C34785E72C996C94B122EBA6F329BE630B1B4C6E2756E7A75392C21E253C6AEACC31FD45FF4595DED375FAF62
# --
# subject= CN = Issuer CA
# 2 0 0 308201683082010DA003020102020102300A06082A8648CE3D04030230123110300E06035504030C07526F6F742043413020170D3135313231333233323030395A180F33303135303431353233323030395A30143112301006035504030C094973737565722043413059301306072A8648CE3D020106082A8648CE3D030107034200047D4BAE18B49F5DC69D0A3C85C66A3E2119DE92CFAD081FAD55C12D510EC97B6C00E13695A8D9713548FE60DF15573390433E2A1BD92DB4B7AA016EC6185DC5AFA350304E301D0603551D0E041604147AB75A3CD295CA5DF7C5150916E18FF5CC376A15301F0603551D23041830168014E4BD405F052A820DDF9883F93D7D3F90AAEC723F300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100831DCD882DA8785D50E41020898C0248879DDDF72D701D1DC1DE6BE08155B43E022100B84B2FB519C4CD3CBC791603D4488F7707597DB7980D9C173E7FDD0ECD7CA308
# 2 0 1 0DAA76425A1FC398C55A643D5A2485AE4CC2B64B9515A75054722B2E83C31BBD
# 2 0 2 6BC0C0F2500320A49392910965263A3EBDD594173D3E36CCE38A003D2EC3FAFBC315EDB776CD3139637DF494FB60359601542A4F821BF0542F926E6270C9762C
# 2 1 0 3059301306072A8648CE3D020106082A8648CE3D030107034200047D4BAE18B49F5DC69D0A3C85C66A3E2119DE92CFAD081FAD55C12D510EC97B6C00E13695A8D9713548FE60DF15573390433E2A1BD92DB4B7AA016EC6185DC5AF
# 2 1 1 65A457617072DA3E7F1152471EB3D406526530097D0A9AA34EB47C990A1FCDA3
# 2 1 2 1F484106F765B6F1AC483CC509CDAD36486A83D1BA115F562516F407C1109303658408B455824DA0785A252B205DBEECB1AFB5DB869E8AAC242091B63F258F05
# --
# subject= CN = Root CA
# 2 0 0 308201643082010BA003020102020101300A06082A8648CE3D04030230123110300E06035504030C07526F6F742043413020170D3135313231333233313330385A180F33303135303431353233313330385A30123110300E06035504030C07526F6F742043413059301306072A8648CE3D020106082A8648CE3D03010703420004D1DA578FD18FB86456B0D91B5656BDD68D4DDBD250E337571127C75E0560F41D0AF91BFAF8805F80C28C026A14D4FE8C30A9673B9EC0C05A84AA810D1341B76CA350304E301D0603551D0E04160414E4BD405F052A820DDF9883F93D7D3F90AAEC723F301F0603551D23041830168014E4BD405F052A820DDF9883F93D7D3F90AAEC723F300C0603551D13040530030101FF300A06082A8648CE3D040302034700304402206869E6AA9F9B4D4BF308091A5A7AB2C30E3619B0D75E528819468E4BB926F4C9022017F1B8458611966FBC109CAED3582966BF25FC0598EABA6C793C58DCC3537CC5
# 2 0 1 FE7C8E01110627A782765E468D8CB4D2CC7907EAC4BA5974CD92B540ED2AAC3C
# 2 0 2 361029F20A3B59DAFAAF05D41811EFC1A9439B972BC6B9D7F13BC5469570E49ACAE0CB0C877C75D58346590EA950AC7A39AED6E8AA8004EA7F5DE3AB9462047E
# 2 1 0 3059301306072A8648CE3D020106082A8648CE3D03010703420004D1DA578FD18FB86456B0D91B5656BDD68D4DDBD250E337571127C75E0560F41D0AF91BFAF8805F80C28C026A14D4FE8C30A9673B9EC0C05A84AA810D1341B76C
# 2 1 1 91D942E4A2D4226DDAF28CADAA7F13018E4ED0D9A43A529247E51C965188576C
# 2 1 2 5F414D4D7BFDF22E39952D9F46C51370FDD050F10C55B4CDB42E40FA98611FDE23EEE9B23315EE1ECDB198C7419E9A2D6742860E4806AF45164507799C3B452E
# Renumber:
# << 'EOF' perl -pe 'BEGIN {$t = 0; $/="\n\n"} if (s/\A\s*# \d+\s*?\n//sm) {printf "# %d\n", ++$t}'
## -- Anonymous and "never valid" leaf certificate DANE-EE(3) tests
# 1
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 1 0 0
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
3 0 0 3081ec308193a003020102020101300a06082a8648ce3d0403023000301e170d3135313231343030313033345a170d3135313231333030313033345a30003059301306072a8648ce3d020106082a8648ce3d03010703420004c5a4ffa008eebc0369b974799f9479cb47360544fafc02c4204fb3df31e88a1a4f18c85831e93f985c5b231094541b4316b5cb1c9c0c950886fe1143f39f6109300a06082a8648ce3d040302034800304502206ae7b7a870df21081e9a9896020aaf8560984875c812b36d671631abc879f872022100b0889ad2b3814ee64bddd5a7f6a98dea43cb435049469cb50a4404cbdeee1fd6
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
subject=
issuer=
notBefore=Dec 14 00:10:34 2015 GMT
notAfter=Dec 13 00:10:34 2015 GMT
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNTEyMTQwMDEwMzRaFw0x
NTEyMTMwMDEwMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATFpP+gCO68
A2m5dHmflHnLRzYFRPr8AsQgT7PfMeiKGk8YyFgx6T+YXFsjEJRUG0MWtcscnAyV
CIb+EUPzn2EJMAoGCCqGSM49BAMCA0gAMEUCIGrnt6hw3yEIHpqYlgIKr4VgmEh1
yBKzbWcWMavIefhyAiEAsIia0rOBTuZL3dWn9qmN6kPLQ1BJRpy1CkQEy97uH9Y=
-----END CERTIFICATE-----
# 2
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 1 0 0
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
3 1 0 3059301306072a8648ce3d020106082a8648ce3d03010703420004c5a4ffa008eebc0369b974799f9479cb47360544fafc02c4204fb3df31e88a1a4f18c85831e93f985c5b231094541b4316b5cb1c9c0c950886fe1143f39f6109
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
subject=
issuer=
notBefore=Dec 14 00:10:34 2015 GMT
notAfter=Dec 13 00:10:34 2015 GMT
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNTEyMTQwMDEwMzRaFw0x
NTEyMTMwMDEwMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATFpP+gCO68
A2m5dHmflHnLRzYFRPr8AsQgT7PfMeiKGk8YyFgx6T+YXFsjEJRUG0MWtcscnAyV
CIb+EUPzn2EJMAoGCCqGSM49BAMCA0gAMEUCIGrnt6hw3yEIHpqYlgIKr4VgmEh1
yBKzbWcWMavIefhyAiEAsIia0rOBTuZL3dWn9qmN6kPLQ1BJRpy1CkQEy97uH9Y=
-----END CERTIFICATE-----
# 3
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 1 0 0
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
3 0 1 588FD5F414E3327EAFE3169DC040AE161247D1296BF38304AB9CF464850A1365
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
subject=
issuer=
notBefore=Dec 14 00:10:34 2015 GMT
notAfter=Dec 13 00:10:34 2015 GMT
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNTEyMTQwMDEwMzRaFw0x
NTEyMTMwMDEwMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATFpP+gCO68
A2m5dHmflHnLRzYFRPr8AsQgT7PfMeiKGk8YyFgx6T+YXFsjEJRUG0MWtcscnAyV
CIb+EUPzn2EJMAoGCCqGSM49BAMCA0gAMEUCIGrnt6hw3yEIHpqYlgIKr4VgmEh1
yBKzbWcWMavIefhyAiEAsIia0rOBTuZL3dWn9qmN6kPLQ1BJRpy1CkQEy97uH9Y=
-----END CERTIFICATE-----
# 4
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 1 0 0
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
3 1 1 05C66146D7909EAE2379825F6D0F5284146B79598DA12E403DC29C33147CF33E
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
subject=
issuer=
notBefore=Dec 14 00:10:34 2015 GMT
notAfter=Dec 13 00:10:34 2015 GMT
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNTEyMTQwMDEwMzRaFw0x
NTEyMTMwMDEwMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATFpP+gCO68
A2m5dHmflHnLRzYFRPr8AsQgT7PfMeiKGk8YyFgx6T+YXFsjEJRUG0MWtcscnAyV
CIb+EUPzn2EJMAoGCCqGSM49BAMCA0gAMEUCIGrnt6hw3yEIHpqYlgIKr4VgmEh1
yBKzbWcWMavIefhyAiEAsIia0rOBTuZL3dWn9qmN6kPLQ1BJRpy1CkQEy97uH9Y=
-----END CERTIFICATE-----
# 5
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
1 1 1 0 0
3 0 2 42BEE929852C8063A0D619B53D0DD35703BBAD2FC25F2055F737C7A14DDFEA544491F8C00F50FA083BD0AD1B5C98529994FF811BBA5E5170CC6EE9F3ED5563E1
subject=
issuer=
notBefore=Dec 14 00:10:34 2015 GMT
notAfter=Dec 13 00:10:34 2015 GMT
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNTEyMTQwMDEwMzRaFw0x
NTEyMTMwMDEwMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATFpP+gCO68
A2m5dHmflHnLRzYFRPr8AsQgT7PfMeiKGk8YyFgx6T+YXFsjEJRUG0MWtcscnAyV
CIb+EUPzn2EJMAoGCCqGSM49BAMCA0gAMEUCIGrnt6hw3yEIHpqYlgIKr4VgmEh1
yBKzbWcWMavIefhyAiEAsIia0rOBTuZL3dWn9qmN6kPLQ1BJRpy1CkQEy97uH9Y=
-----END CERTIFICATE-----
# 6
1 1 1 0 0
3 1 2 D91A3E5DC34879CD77AD1E989F56FA78FACADF05EF8D445EDF5652BD58EE392C87C02F84C0119D62309041F2D5128A73399DF25D1F47BCD497357EAF1A1009A3
subject=
issuer=
notBefore=Dec 14 00:10:34 2015 GMT
notAfter=Dec 13 00:10:34 2015 GMT
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNTEyMTQwMDEwMzRaFw0x
NTEyMTMwMDEwMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATFpP+gCO68
A2m5dHmflHnLRzYFRPr8AsQgT7PfMeiKGk8YyFgx6T+YXFsjEJRUG0MWtcscnAyV
CIb+EUPzn2EJMAoGCCqGSM49BAMCA0gAMEUCIGrnt6hw3yEIHpqYlgIKr4VgmEh1
yBKzbWcWMavIefhyAiEAsIia0rOBTuZL3dWn9qmN6kPLQ1BJRpy1CkQEy97uH9Y=
-----END CERTIFICATE-----
# 7
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 1 65 -1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
3 0 1 588FD5F414E3327EAFE3169DC040AE161247D1296BF38304AB9CF464850A1366
subject=
issuer=
notBefore=Dec 14 00:10:34 2015 GMT
notAfter=Dec 13 00:10:34 2015 GMT
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNTEyMTQwMDEwMzRaFw0x
NTEyMTMwMDEwMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATFpP+gCO68
A2m5dHmflHnLRzYFRPr8AsQgT7PfMeiKGk8YyFgx6T+YXFsjEJRUG0MWtcscnAyV
CIb+EUPzn2EJMAoGCCqGSM49BAMCA0gAMEUCIGrnt6hw3yEIHpqYlgIKr4VgmEh1
yBKzbWcWMavIefhyAiEAsIia0rOBTuZL3dWn9qmN6kPLQ1BJRpy1CkQEy97uH9Y=
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 8
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 1 65 -1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
3 1 1 05C66146D7909EAE2379825F6D0F5284146B79598DA12E403DC29C33147CF33F
subject=
issuer=
notBefore=Dec 14 00:10:34 2015 GMT
notAfter=Dec 13 00:10:34 2015 GMT
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNTEyMTQwMDEwMzRaFw0x
NTEyMTMwMDEwMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATFpP+gCO68
A2m5dHmflHnLRzYFRPr8AsQgT7PfMeiKGk8YyFgx6T+YXFsjEJRUG0MWtcscnAyV
CIb+EUPzn2EJMAoGCCqGSM49BAMCA0gAMEUCIGrnt6hw3yEIHpqYlgIKr4VgmEh1
yBKzbWcWMavIefhyAiEAsIia0rOBTuZL3dWn9qmN6kPLQ1BJRpy1CkQEy97uH9Y=
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 9
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 1 65 -1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
3 0 2 42BEE929852C8063A0D619B53D0DD35703BBAD2FC25F2055F737C7A14DDFEA544491F8C00F50FA083BD0AD1B5C98529994FF811BBA5E5170CC6EE9F3ED5563E2
subject=
issuer=
notBefore=Dec 14 00:10:34 2015 GMT
notAfter=Dec 13 00:10:34 2015 GMT
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNTEyMTQwMDEwMzRaFw0x
NTEyMTMwMDEwMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATFpP+gCO68
A2m5dHmflHnLRzYFRPr8AsQgT7PfMeiKGk8YyFgx6T+YXFsjEJRUG0MWtcscnAyV
CIb+EUPzn2EJMAoGCCqGSM49BAMCA0gAMEUCIGrnt6hw3yEIHpqYlgIKr4VgmEh1
yBKzbWcWMavIefhyAiEAsIia0rOBTuZL3dWn9qmN6kPLQ1BJRpy1CkQEy97uH9Y=
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 10
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 1 65 -1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
3 1 2 D91A3E5DC34879CD77AD1E989F56FA78FACADF05EF8D445EDF5652BD58EE392C87C02F84C0119D62309041F2D5128A73399DF25D1F47BCD497357EAF1A1009A4
subject=
issuer=
notBefore=Dec 14 00:10:34 2015 GMT
notAfter=Dec 13 00:10:34 2015 GMT
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNTEyMTQwMDEwMzRaFw0x
NTEyMTMwMDEwMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATFpP+gCO68
A2m5dHmflHnLRzYFRPr8AsQgT7PfMeiKGk8YyFgx6T+YXFsjEJRUG0MWtcscnAyV
CIb+EUPzn2EJMAoGCCqGSM49BAMCA0gAMEUCIGrnt6hw3yEIHpqYlgIKr4VgmEh1
yBKzbWcWMavIefhyAiEAsIia0rOBTuZL3dWn9qmN6kPLQ1BJRpy1CkQEy97uH9Y=
-----END CERTIFICATE-----
## -- DANE-?? chain tests --
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 11
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
3 0 1 BEDC04764CECAE80AEE454D332758F50847DCA424216466E4012E0DEAE1F2E5F
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 12
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
3 1 1 3111668338043DE264D0256A702248696C9484B6221A42740F920187B4C61838
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 13
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
3 0 2 F756CCD61F3CA50D017653911701CA0052AF0B29E273DD263DD23643D86D4369D03686BD1369EF54BB2DC2DAE3CE4F05AF39D54648F94D54AA86B259AEAD9923
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 14
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
3 1 2 CB861AF6DDED185EE04472A9092052CCC735120C34785E72C996C94B122EBA6F329BE630B1B4C6E2756E7A75392C21E253C6AEACC31FD45FF4595DED375FAF62
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 15
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 0 1 0DAA76425A1FC398C55A643D5A2485AE4CC2B64B9515A75054722B2E83C31BBD
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 16
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 1 1 65A457617072DA3E7F1152471EB3D406526530097D0A9AA34EB47C990A1FCDA3
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 17
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 0 2 6BC0C0F2500320A49392910965263A3EBDD594173D3E36CCE38A003D2EC3FAFBC315EDB776CD3139637DF494FB60359601542A4F821BF0542F926E6270C9762C
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 18
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 1 2 1F484106F765B6F1AC483CC509CDAD36486A83D1BA115F562516F407C1109303658408B455824DA0785A252B205DBEECB1AFB5DB869E8AAC242091B63F258F05
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 19
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 0 1 FE7C8E01110627A782765E468D8CB4D2CC7907EAC4BA5974CD92B540ED2AAC3C
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 20
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 1 1 91D942E4A2D4226DDAF28CADAA7F13018E4ED0D9A43A529247E51C965188576C
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 21
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 0 2 361029F20A3B59DAFAAF05D41811EFC1A9439B972BC6B9D7F13BC5469570E49ACAE0CB0C877C75D58346590EA950AC7A39AED6E8AA8004EA7F5DE3AB9462047E
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 22
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 1 2 5F414D4D7BFDF22E39952D9F46C51370FDD050F10C55B4CDB42E40FA98611FDE23EEE9B23315EE1ECDB198C7419E9A2D6742860E4806AF45164507799C3B452E
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
## -- PKIX-?? chain tests --
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 23
1 2 0 0 0
1 0 0 308201943082013ba003020102020102300a06082a8648ce3d04030230143112301006035504030c094973737565722043413020170d3135313231333233323335325a180f33303135303431353233323335325a30163114301206035504030c0b6578616d706c652e636f6d3059301306072a8648ce3d020106082a8648ce3d03010703420004664995f47bde35e7b4de48b258e9e8a07adebbdb863b3d06f481a1946c83da9f56cff4d9389b855d2f364b1585b0c734fcfa263026964ff5a4308b3fc879bdb8a37a3078301d0603551d0e041604145b20ca417d9088c7a4c017cb6c0c1c739bb07d8a301f0603551d230418301680147ab75a3cd295ca5df7c5150916e18ff5cc376a1530090603551d130402300030130603551d25040c300a06082b0601050507030130160603551d11040f300d820b6578616d706c652e636f6d300a06082a8648ce3d0403020347003044021f21c9032a5c8a93872d3f4aef321a9574dd956d43bd93c369944c72d6902858022100c8b3290d7af37e571a84d704dbad339d2987d41852dc5936f212947063911181
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
# 24
1 2 0 0 0
1 1 0 3059301306072a8648ce3d020106082a8648ce3d03010703420004664995f47bde35e7b4de48b258e9e8a07adebbdb863b3d06f481a1946c83da9f56cff4d9389b855d2f364b1585b0c734fcfa263026964ff5a4308b3fc879bdb8
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
# 25
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 2 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
1 0 1 BEDC04764CECAE80AEE454D332758F50847DCA424216466E4012E0DEAE1F2E5F
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 26
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 2 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
1 1 1 3111668338043DE264D0256A702248696C9484B6221A42740F920187B4C61838
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 27
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
1 0 2 F756CCD61F3CA50D017653911701CA0052AF0B29E273DD263DD23643D86D4369D03686BD1369EF54BB2DC2DAE3CE4F05AF39D54648F94D54AA86B259AEAD9923
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 28
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
1 1 2 CB861AF6DDED185EE04472A9092052CCC735120C34785E72C996C94B122EBA6F329BE630B1B4C6E2756E7A75392C21E253C6AEACC31FD45FF4595DED375FAF62
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 29
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 2 0 0 1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
0 0 1 0DAA76425A1FC398C55A643D5A2485AE4CC2B64B9515A75054722B2E83C31BBD
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 30
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 2 0 0 1
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
0 1 0 3059301306072a8648ce3d020106082a8648ce3d030107034200047d4bae18b49f5dc69d0a3c85c66a3e2119de92cfad081fad55c12d510ec97b6c00e13695a8d9713548fe60df15573390433e2a1bd92db4b7aa016ec6185dc5af
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
Fix freshly introduced double-free. We don't need the decoded X.509 Full(0) certificate for the EE usages 1 and 3, because the leaf certificate is always part of the presented chain, so the certificate is only validated as well-formed, and then discarded, but the TLSA record is of course still used after the validation step. Added DANE test cases for: 3 0 0, 3 1 0, 1 0 0, and 1 1 0 Reported by Claus Assmann. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-26 02:26:20 +08:00
# 31
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
1 2 0 0 1
0 1 1 65A457617072DA3E7F1152471EB3D406526530097D0A9AA34EB47C990A1FCDA3
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
# 32
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
0 0 2 6BC0C0F2500320A49392910965263A3EBDD594173D3E36CCE38A003D2EC3FAFBC315EDB776CD3139637DF494FB60359601542A4F821BF0542F926E6270C9762C
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 33
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
0 1 2 1F484106F765B6F1AC483CC509CDAD36486A83D1BA115F562516F407C1109303658408B455824DA0785A252B205DBEECB1AFB5DB869E8AAC242091B63F258F05
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 34
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 2 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
0 0 1 FE7C8E01110627A782765E468D8CB4D2CC7907EAC4BA5974CD92B540ED2AAC3C
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 35
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 2 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
0 1 1 91D942E4A2D4226DDAF28CADAA7F13018E4ED0D9A43A529247E51C965188576C
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 36
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
0 0 2 361029F20A3B59DAFAAF05D41811EFC1A9439B972BC6B9D7F13BC5469570E49ACAE0CB0C877C75D58346590EA950AC7A39AED6E8AA8004EA7F5DE3AB9462047E
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 37
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
0 1 2 5F414D4D7BFDF22E39952D9F46C51370FDD050F10C55B4CDB42E40FA98611FDE23EEE9B23315EE1ECDB198C7419E9A2D6742860E4806AF45164507799C3B452E
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
## -- PKIX-?? chain failures --
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 38
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
# Missing intermediate CA
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 0 20 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
1 0 1 BEDC04764CECAE80AEE454D332758F50847DCA424216466E4012E0DEAE1F2E5F
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 39
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
# Missing PKIX intermediate, provided via DNS
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
2 1 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
1 1 1 3111668338043DE264D0256A702248696C9484B6221A42740F920187B4C61838
0 0 0 308201683082010DA003020102020102300A06082A8648CE3D04030230123110300E06035504030C07526F6F742043413020170D3135313231333233323030395A180F33303135303431353233323030395A30143112301006035504030C094973737565722043413059301306072A8648CE3D020106082A8648CE3D030107034200047D4BAE18B49F5DC69D0A3C85C66A3E2119DE92CFAD081FAD55C12D510EC97B6C00E13695A8D9713548FE60DF15573390433E2A1BD92DB4B7AA016EC6185DC5AFA350304E301D0603551D0E041604147AB75A3CD295CA5DF7C5150916E18FF5CC376A15301F0603551D23041830168014E4BD405F052A820DDF9883F93D7D3F90AAEC723F300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100831DCD882DA8785D50E41020898C0248879DDDF72D701D1DC1DE6BE08155B43E022100B84B2FB519C4CD3CBC791603D4488F7707597DB7980D9C173E7FDD0ECD7CA308
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 40
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
# Wrong leaf digest
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 65 -1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
1 0 2 F756CCD61F3CA50D017653911701CA0052AF0B29E273DD263DD23643D86D4369D03686BD1369EF54BB2DC2DAE3CE4F05AF39D54648F94D54AA86B259AEAD9924
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 41
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
# Wrong intermediate digest
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 2 0 65 -1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
0 0 1 0DAA76425A1FC398C55A643D5A2485AE4CC2B64B9515A75054722B2E83C31BBE
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 42
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
# Wrong root digest
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 2 0 65 -1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
0 0 1 FE7C8E01110627A782765E468D8CB4D2CC7907EAC4BA5974CD92B540ED2AAC3D
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
## -- Mixed usage cases
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 43
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# DANE-EE(3) beats DANE-TA(2)
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
3 1 2 CB861AF6DDED185EE04472A9092052CCC735120C34785E72C996C94B122EBA6F329BE630B1B4C6E2756E7A75392C21E253C6AEACC31FD45FF4595DED375FAF62
2 1 2 5F414D4D7BFDF22E39952D9F46C51370FDD050F10C55B4CDB42E40FA98611FDE23EEE9B23315EE1ECDB198C7419E9A2D6742860E4806AF45164507799C3B452E
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 44
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# DANE-TA(2) depth 1 beats DANE-TA(2) depth 2
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 1 2 1F484106F765B6F1AC483CC509CDAD36486A83D1BA115F562516F407C1109303658408B455824DA0785A252B205DBEECB1AFB5DB869E8AAC242091B63F258F05
2 1 2 5F414D4D7BFDF22E39952D9F46C51370FDD050F10C55B4CDB42E40FA98611FDE23EEE9B23315EE1ECDB198C7419E9A2D6742860E4806AF45164507799C3B452E
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 45
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# DANE-TA(2) depth 2 beats PKIX-TA(0) depth 1
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 0 1 FE7C8E01110627A782765E468D8CB4D2CC7907EAC4BA5974CD92B540ED2AAC3C
0 0 1 0DAA76425A1FC398C55A643D5A2485AE4CC2B64B9515A75054722B2E83C31BBD
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 46
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# DANE-TA(2) depth 2 beats PKIX-EE depth 0
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 0 1 FE7C8E01110627A782765E468D8CB4D2CC7907EAC4BA5974CD92B540ED2AAC3C
0 0 1 0DAA76425A1FC398C55A643D5A2485AE4CC2B64B9515A75054722B2E83C31BBD
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
subject= /CN=Root CA
issuer= /CN=Root CA
notBefore=Dec 13 23:13:08 2015 GMT
notAfter=Apr 15 23:13:08 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 47
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# DANE-TA(2) Full(0) root "from DNS":
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 2 0 0 2
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 0 0 308201643082010BA003020102020101300A06082A8648CE3D04030230123110300E06035504030C07526F6F742043413020170D3135313231333233313330385A180F33303135303431353233313330385A30123110300E06035504030C07526F6F742043413059301306072A8648CE3D020106082A8648CE3D03010703420004D1DA578FD18FB86456B0D91B5656BDD68D4DDBD250E337571127C75E0560F41D0AF91BFAF8805F80C28C026A14D4FE8C30A9673B9EC0C05A84AA810D1341B76CA350304E301D0603551D0E04160414E4BD405F052A820DDF9883F93D7D3F90AAEC723F301F0603551D23041830168014E4BD405F052A820DDF9883F93D7D3F90AAEC723F300C0603551D13040530030101FF300A06082A8648CE3D040302034700304402206869E6AA9F9B4D4BF308091A5A7AB2C30E3619B0D75E528819468E4BB926F4C9022017F1B8458611966FBC109CAED3582966BF25FC0598EABA6C793C58DCC3537CC5
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 48
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# DANE-TA(2) Full(0) intermediate "from DNS":
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 0 0 1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 0 0 308201683082010DA003020102020102300A06082A8648CE3D04030230123110300E06035504030C07526F6F742043413020170D3135313231333233323030395A180F33303135303431353233323030395A30143112301006035504030C094973737565722043413059301306072A8648CE3D020106082A8648CE3D030107034200047D4BAE18B49F5DC69D0A3C85C66A3E2119DE92CFAD081FAD55C12D510EC97B6C00E13695A8D9713548FE60DF15573390433E2A1BD92DB4B7AA016EC6185DC5AFA350304E301D0603551D0E041604147AB75A3CD295CA5DF7C5150916E18FF5CC376A15301F0603551D23041830168014E4BD405F052A820DDF9883F93D7D3F90AAEC723F300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100831DCD882DA8785D50E41020898C0248879DDDF72D701D1DC1DE6BE08155B43E022100B84B2FB519C4CD3CBC791603D4488F7707597DB7980D9C173E7FDD0ECD7CA308
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 49
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# DANE-TA(2) SPKI(1) Full(0) intermediate "from DNS":
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 1 0 0 0
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 1 0 3059301306072A8648CE3D020106082A8648CE3D030107034200047D4BAE18B49F5DC69D0A3C85C66A3E2119DE92CFAD081FAD55C12D510EC97B6C00E13695A8D9713548FE60DF15573390433E2A1BD92DB4B7AA016EC6185DC5AF
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 50
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# DANE-TA(2) SPKI(1) Full(0) root "from DNS":
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 2 0 0 1
DANE support for X509_verify_cert() Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-12-30 03:12:36 +08:00
2 1 0 3059301306072A8648CE3D020106082A8648CE3D03010703420004D1DA578FD18FB86456B0D91B5656BDD68D4DDBD250E337571127C75E0560F41D0AF91BFAF8805F80C28C026A14D4FE8C30A9673B9EC0C05A84AA810D1341B76C
subject= /CN=example.com
issuer= /CN=Issuer CA
notBefore=Dec 13 23:23:52 2015 GMT
notAfter=Apr 15 23:23:52 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGB
-----END CERTIFICATE-----
subject= /CN=Issuer CA
issuer= /CN=Root CA
notBefore=Dec 13 23:20:09 2015 GMT
notAfter=Apr 15 23:20:09 3015 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBAjAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
MCAXDTE1MTIxMzIzMjAwOVoYDzMwMTUwNDE1MjMyMDA5WjAUMRIwEAYDVQQDDAlJ
c3N1ZXIgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR9S64YtJ9dxp0KPIXG
aj4hGd6Sz60IH61VwS1RDsl7bADhNpWo2XE1SP5g3xVXM5BDPiob2S20t6oBbsYY
XcWvo1AwTjAdBgNVHQ4EFgQUerdaPNKVyl33xRUJFuGP9cw3ahUwHwYDVR0jBBgw
FoAU5L1AXwUqgg3fmIP5PX0/kKrscj8wDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAgx3NiC2oeF1Q5BAgiYwCSIed3fctcB0dwd5r4IFVtD4CIQC4Sy+1
GcTNPLx5FgPUSI93B1l9t5gNnBc+f90OzXyjCA==
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 51
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# Mismatched name "example.org", should still succeed given a
# DANE-EE(3) match.
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 1 0 0
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
3 1 1 ee1477190203f5d8b4767f4451b89e7367cdec7f6965a4988227983562ac8270
subject= CN = example.org
issuer= CN = CA2
notBefore=Feb 6 22:39:47 2016 GMT
notAfter=Feb 7 22:39:47 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBkDCCATWgAwIBAgIBAjAKBggqhkjOPQQDAjAOMQwwCgYDVQQDDANDQTIwIBcN
MTYwMjA2MjIzOTQ3WhgPMjExNjAyMDcyMjM5NDdaMBYxFDASBgNVBAMMC2V4YW1w
bGUub3JnMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE/YCEn0pxClPTvpjioxU4
ajopRa4j/6XTqxy9zqn1AcMCiVWp6j22B6RpLmKEHoRHQxFzebd2juTXIDq81CID
z6N6MHgwHQYDVR0OBBYEFOrSA+2YKXa5KR6k0687CZuhai5OMB8GA1UdIwQYMBaA
FLTY4vqgjcQ01aCcB8AYVbUhEU7VMAkGA1UdEwQCMAAwEwYDVR0lBAwwCgYIKwYB
BQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5vcmcwCgYIKoZIzj0EAwIDSQAwRgIh
AKSsLwlidPiSrgda6XWihov4D4KHu6ZX3ZAAZ2uiBAefAiEArCq5WiO3Zeunl0Ct
PyDiaL1QKbJ7lnqPQCS1o8xn+RI=
-----END CERTIFICATE-----
subject= CN = CA2
issuer= CN = Root CA2
notBefore=Feb 6 22:39:13 2016 GMT
notAfter=Feb 7 22:39:13 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBYjCCAQigAwIBAgIBAjAKBggqhkjOPQQDAjATMREwDwYDVQQDDAhSb290IENB
MjAgFw0xNjAyMDYyMjM5MTNaGA8yMTE2MDIwNzIyMzkxM1owDjEMMAoGA1UEAwwD
Q0EyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEYr6zgBxpsxA31IFiGyb6uaGC
CQdNMyJfDgqCihsU1eOEuauzXO7tydCbjfRmhqQK1EGd254IjcGY+37tZEbvPKNQ
ME4wHQYDVR0OBBYEFLTY4vqgjcQ01aCcB8AYVbUhEU7VMB8GA1UdIwQYMBaAFBRb
+/qrntsksembakoZTwTZk8AXMAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwIDSAAw
RQIgX2fmMykyiuryf1AeKyc1j8HgmM8u/nyQfJnTCwvYUcECIQC6JHd3ybV9eJQo
7sfr/jV+rRlZY2iaRv160BWYd82L7g==
-----END CERTIFICATE-----
subject= CN = Root CA2
issuer= CN = Root CA2
notBefore=Feb 6 22:38:48 2016 GMT
notAfter=Feb 7 22:38:48 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBATAKBggqhkjOPQQDAjATMREwDwYDVQQDDAhSb290IENB
MjAgFw0xNjAyMDYyMjM4NDhaGA8yMTE2MDIwNzIyMzg0OFowEzERMA8GA1UEAwwI
Um9vdCBDQTIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATlTxAPKteg+L1LmxMl
sbAFMxj6/322nR5RRGeF07KZRBFPaFZLgwZ1DuNrwM3wxxNdUyoZ6iAyDmwNf3K1
42/Uo1AwTjAdBgNVHQ4EFgQUFFv7+que2ySx6ZtqShlPBNmTwBcwHwYDVR0jBBgw
FoAUFFv7+que2ySx6ZtqShlPBNmTwBcwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAumhPWZ37swl10awM/amX+jv0UlUyJBf8RGA6QMG5bwICIQDbinER
fEevg+GOsr1P6nNMCAsQd9NwsvTQ+jm+TBArWQ==
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 52
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# Mismatched name "example.org", should fail despite a DANE-TA(2)
# match for the intermediate CA.
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 62 1
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
2 1 1 946af0956378efaba7ee1bbedc17af110ea8de19c079a98e77398724a3708a1f
subject= CN = example.org
issuer= CN = CA2
notBefore=Feb 6 22:39:47 2016 GMT
notAfter=Feb 7 22:39:47 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBkDCCATWgAwIBAgIBAjAKBggqhkjOPQQDAjAOMQwwCgYDVQQDDANDQTIwIBcN
MTYwMjA2MjIzOTQ3WhgPMjExNjAyMDcyMjM5NDdaMBYxFDASBgNVBAMMC2V4YW1w
bGUub3JnMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE/YCEn0pxClPTvpjioxU4
ajopRa4j/6XTqxy9zqn1AcMCiVWp6j22B6RpLmKEHoRHQxFzebd2juTXIDq81CID
z6N6MHgwHQYDVR0OBBYEFOrSA+2YKXa5KR6k0687CZuhai5OMB8GA1UdIwQYMBaA
FLTY4vqgjcQ01aCcB8AYVbUhEU7VMAkGA1UdEwQCMAAwEwYDVR0lBAwwCgYIKwYB
BQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5vcmcwCgYIKoZIzj0EAwIDSQAwRgIh
AKSsLwlidPiSrgda6XWihov4D4KHu6ZX3ZAAZ2uiBAefAiEArCq5WiO3Zeunl0Ct
PyDiaL1QKbJ7lnqPQCS1o8xn+RI=
-----END CERTIFICATE-----
subject= CN = CA2
issuer= CN = Root CA2
notBefore=Feb 6 22:39:13 2016 GMT
notAfter=Feb 7 22:39:13 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBYjCCAQigAwIBAgIBAjAKBggqhkjOPQQDAjATMREwDwYDVQQDDAhSb290IENB
MjAgFw0xNjAyMDYyMjM5MTNaGA8yMTE2MDIwNzIyMzkxM1owDjEMMAoGA1UEAwwD
Q0EyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEYr6zgBxpsxA31IFiGyb6uaGC
CQdNMyJfDgqCihsU1eOEuauzXO7tydCbjfRmhqQK1EGd254IjcGY+37tZEbvPKNQ
ME4wHQYDVR0OBBYEFLTY4vqgjcQ01aCcB8AYVbUhEU7VMB8GA1UdIwQYMBaAFBRb
+/qrntsksembakoZTwTZk8AXMAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwIDSAAw
RQIgX2fmMykyiuryf1AeKyc1j8HgmM8u/nyQfJnTCwvYUcECIQC6JHd3ybV9eJQo
7sfr/jV+rRlZY2iaRv160BWYd82L7g==
-----END CERTIFICATE-----
subject= CN = Root CA2
issuer= CN = Root CA2
notBefore=Feb 6 22:38:48 2016 GMT
notAfter=Feb 7 22:38:48 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBATAKBggqhkjOPQQDAjATMREwDwYDVQQDDAhSb290IENB
MjAgFw0xNjAyMDYyMjM4NDhaGA8yMTE2MDIwNzIyMzg0OFowEzERMA8GA1UEAwwI
Um9vdCBDQTIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATlTxAPKteg+L1LmxMl
sbAFMxj6/322nR5RRGeF07KZRBFPaFZLgwZ1DuNrwM3wxxNdUyoZ6iAyDmwNf3K1
42/Uo1AwTjAdBgNVHQ4EFgQUFFv7+que2ySx6ZtqShlPBNmTwBcwHwYDVR0jBBgw
FoAUFFv7+que2ySx6ZtqShlPBNmTwBcwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAumhPWZ37swl10awM/amX+jv0UlUyJBf8RGA6QMG5bwICIQDbinER
fEevg+GOsr1P6nNMCAsQd9NwsvTQ+jm+TBArWQ==
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 53
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
# Mismatched name "example.org", should fail despite a DANE-TA(2)
# match for the root CA.
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
1 3 0 62 2
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
2 1 1 34474f2fbc39da44dfbd11215bdafadf9507406c04de1f65dbd2a1bc4f2165cc
subject= CN = example.org
issuer= CN = CA2
notBefore=Feb 6 22:39:47 2016 GMT
notAfter=Feb 7 22:39:47 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBkDCCATWgAwIBAgIBAjAKBggqhkjOPQQDAjAOMQwwCgYDVQQDDANDQTIwIBcN
MTYwMjA2MjIzOTQ3WhgPMjExNjAyMDcyMjM5NDdaMBYxFDASBgNVBAMMC2V4YW1w
bGUub3JnMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE/YCEn0pxClPTvpjioxU4
ajopRa4j/6XTqxy9zqn1AcMCiVWp6j22B6RpLmKEHoRHQxFzebd2juTXIDq81CID
z6N6MHgwHQYDVR0OBBYEFOrSA+2YKXa5KR6k0687CZuhai5OMB8GA1UdIwQYMBaA
FLTY4vqgjcQ01aCcB8AYVbUhEU7VMAkGA1UdEwQCMAAwEwYDVR0lBAwwCgYIKwYB
BQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5vcmcwCgYIKoZIzj0EAwIDSQAwRgIh
AKSsLwlidPiSrgda6XWihov4D4KHu6ZX3ZAAZ2uiBAefAiEArCq5WiO3Zeunl0Ct
PyDiaL1QKbJ7lnqPQCS1o8xn+RI=
-----END CERTIFICATE-----
subject= CN = CA2
issuer= CN = Root CA2
notBefore=Feb 6 22:39:13 2016 GMT
notAfter=Feb 7 22:39:13 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBYjCCAQigAwIBAgIBAjAKBggqhkjOPQQDAjATMREwDwYDVQQDDAhSb290IENB
MjAgFw0xNjAyMDYyMjM5MTNaGA8yMTE2MDIwNzIyMzkxM1owDjEMMAoGA1UEAwwD
Q0EyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEYr6zgBxpsxA31IFiGyb6uaGC
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
CQdNMyJfDgqCihsU1eOEuauzXO7tydCbjfRmhqQK1EGd254IjcGY+37tZEbvPKNQ
ME4wHQYDVR0OBBYEFLTY4vqgjcQ01aCcB8AYVbUhEU7VMB8GA1UdIwQYMBaAFBRb
+/qrntsksembakoZTwTZk8AXMAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwIDSAAw
RQIgX2fmMykyiuryf1AeKyc1j8HgmM8u/nyQfJnTCwvYUcECIQC6JHd3ybV9eJQo
7sfr/jV+rRlZY2iaRv160BWYd82L7g==
-----END CERTIFICATE-----
subject= CN = Root CA2
issuer= CN = Root CA2
notBefore=Feb 6 22:38:48 2016 GMT
notAfter=Feb 7 22:38:48 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBATAKBggqhkjOPQQDAjATMREwDwYDVQQDDAhSb290IENB
MjAgFw0xNjAyMDYyMjM4NDhaGA8yMTE2MDIwNzIyMzg0OFowEzERMA8GA1UEAwwI
Um9vdCBDQTIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATlTxAPKteg+L1LmxMl
sbAFMxj6/322nR5RRGeF07KZRBFPaFZLgwZ1DuNrwM3wxxNdUyoZ6iAyDmwNf3K1
42/Uo1AwTjAdBgNVHQ4EFgQUFFv7+que2ySx6ZtqShlPBNmTwBcwHwYDVR0jBBgw
FoAUFFv7+que2ySx6ZtqShlPBNmTwBcwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAumhPWZ37swl10awM/amX+jv0UlUyJBf8RGA6QMG5bwICIQDbinER
fEevg+GOsr1P6nNMCAsQd9NwsvTQ+jm+TBArWQ==
-----END CERTIFICATE-----
Add last missing TLSA usage/selector/mtype test case There were no PKIX-TA(0) SPKI(1) Full(0) (i.e. "0 1 0") test cases in "danetest.in". There is now at least a success case, which will exercise freeing the public key after it is sanity checked, since with PKIX-TA(0) there's nothing we can do with just the raw public key, a full chain to a local trust anchor is in any case required. The failure (to match) code path is already well oiled, but failure to decode while adding malfored TLSA records could still use some additional tests... Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22821)
2023-11-28 00:23:54 +08:00
# 54
Perform DANE-EE(3) name checks by default In light of potential UKS (unknown key share) attacks on some applications, primarily browsers, despite RFC761, name checks are by default applied with DANE-EE(3) TLSA records. Applications for which UKS is not a problem can optionally disable DANE-EE(3) name checks via the new SSL_CTX_dane_set_flags() and friends. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-11 08:36:02 +08:00
# Mismatched name "example.org", should fail when name checks
# are not disabled for DANE-EE(3).
1 3 0 62 0
3 1 1 ee1477190203f5d8b4767f4451b89e7367cdec7f6965a4988227983562ac8270
subject= CN = example.org
issuer= CN = CA2
notBefore=Feb 6 22:39:47 2016 GMT
notAfter=Feb 7 22:39:47 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBkDCCATWgAwIBAgIBAjAKBggqhkjOPQQDAjAOMQwwCgYDVQQDDANDQTIwIBcN
MTYwMjA2MjIzOTQ3WhgPMjExNjAyMDcyMjM5NDdaMBYxFDASBgNVBAMMC2V4YW1w
bGUub3JnMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE/YCEn0pxClPTvpjioxU4
ajopRa4j/6XTqxy9zqn1AcMCiVWp6j22B6RpLmKEHoRHQxFzebd2juTXIDq81CID
z6N6MHgwHQYDVR0OBBYEFOrSA+2YKXa5KR6k0687CZuhai5OMB8GA1UdIwQYMBaA
FLTY4vqgjcQ01aCcB8AYVbUhEU7VMAkGA1UdEwQCMAAwEwYDVR0lBAwwCgYIKwYB
BQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5vcmcwCgYIKoZIzj0EAwIDSQAwRgIh
AKSsLwlidPiSrgda6XWihov4D4KHu6ZX3ZAAZ2uiBAefAiEArCq5WiO3Zeunl0Ct
PyDiaL1QKbJ7lnqPQCS1o8xn+RI=
-----END CERTIFICATE-----
subject= CN = CA2
issuer= CN = Root CA2
notBefore=Feb 6 22:39:13 2016 GMT
notAfter=Feb 7 22:39:13 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBYjCCAQigAwIBAgIBAjAKBggqhkjOPQQDAjATMREwDwYDVQQDDAhSb290IENB
MjAgFw0xNjAyMDYyMjM5MTNaGA8yMTE2MDIwNzIyMzkxM1owDjEMMAoGA1UEAwwD
Q0EyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEYr6zgBxpsxA31IFiGyb6uaGC
Suppress DANE TLSA reflection when verification fails As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa() are expected to return a negative match depth and nothing else when verification fails. However, this only happened when verification failed during chain construction. Errors in verification of the constructed chain did not have the intended effect on these functions. This commit updates the functions to check for verify_result == X509_V_OK, and no longer erases any accumulated match information when chain construction fails. Sophisticated developers can, with care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA info even when verification fail. They must of course first check and save the real error, and restore the original error as quickly as possible. Hiding by default seems to be the safer interface. Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED. This also changes the "-brief" output from s_client to include verification results and TLSA match information. Mentioned session resumption in code example in SSL_CTX_dane_enable(3). Also mentioned that depths returned are relative to the verified chain which is now available via SSL_get0_verified_chain(3). Added a few more test-cases to danetest, that exercise the new code. Resolved thread safety issue in use of static buffer in X509_verify_cert_error_string(). Fixed long-stating issue in apps/s_cb.c which always sets verify_error to either X509_V_OK or "chain to long", code elsewhere (e.g. s_time.c), seems to expect the actual error. [ The new chain construction code is expected to correctly generate "chain too long" errors, so at some point we need to drop the work-arounds, once SSL_set_verify_depth() is also fixed to propagate the depth to X509_STORE_CTX reliably. ] Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-08 08:07:57 +08:00
CQdNMyJfDgqCihsU1eOEuauzXO7tydCbjfRmhqQK1EGd254IjcGY+37tZEbvPKNQ
ME4wHQYDVR0OBBYEFLTY4vqgjcQ01aCcB8AYVbUhEU7VMB8GA1UdIwQYMBaAFBRb
+/qrntsksembakoZTwTZk8AXMAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwIDSAAw
RQIgX2fmMykyiuryf1AeKyc1j8HgmM8u/nyQfJnTCwvYUcECIQC6JHd3ybV9eJQo
7sfr/jV+rRlZY2iaRv160BWYd82L7g==
-----END CERTIFICATE-----
subject= CN = Root CA2
issuer= CN = Root CA2
notBefore=Feb 6 22:38:48 2016 GMT
notAfter=Feb 7 22:38:48 2116 GMT
-----BEGIN CERTIFICATE-----
MIIBaDCCAQ2gAwIBAgIBATAKBggqhkjOPQQDAjATMREwDwYDVQQDDAhSb290IENB
MjAgFw0xNjAyMDYyMjM4NDhaGA8yMTE2MDIwNzIyMzg0OFowEzERMA8GA1UEAwwI
Um9vdCBDQTIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATlTxAPKteg+L1LmxMl
sbAFMxj6/322nR5RRGeF07KZRBFPaFZLgwZ1DuNrwM3wxxNdUyoZ6iAyDmwNf3K1
42/Uo1AwTjAdBgNVHQ4EFgQUFFv7+que2ySx6ZtqShlPBNmTwBcwHwYDVR0jBBgw
FoAUFFv7+que2ySx6ZtqShlPBNmTwBcwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQD
AgNJADBGAiEAumhPWZ37swl10awM/amX+jv0UlUyJBf8RGA6QMG5bwICIQDbinER
fEevg+GOsr1P6nNMCAsQd9NwsvTQ+jm+TBArWQ==
-----END CERTIFICATE-----
Reference in New Issue Copy Permalink