yuzu-emu/mbedtls
1
0
Fork 0
mirror of https://github.com/yuzu-emu/mbedtls.git synced 2024-11-24 02:45:39 +01:00
Code Issues Packages Projects Releases Wiki Activity
8a1face5a5
mbedtls/tests/data_files/server2-sha256.crt

21 lines
1.1 KiB
Plaintext
Raw Normal View History

Test that SHA-1 defaults off Added tests to validate that certificates signed using SHA-1 are rejected by default, but accepted if SHA-1 is explicitly enabled.
2017-05-09 15:59:24 +02:00
-----BEGIN CERTIFICATE-----
Regenerate server2-sha256.crt with a PrintableString issuer server2-sha256.crt had the issuer ON and CN encoded as UTF8String, but the corresponding CA certificate test-ca_cat12.crt had them encoded as PrintableString. The strings matched, which is sufficient according to RFC 5280 §7.1 and RFC 4518 §2.1. However, GnuTLS 3.4.10 requires the strings to have the same encoding, so it did not accept that the UTF8String "PolarSSL Test CA" certificate was signed by the PrintableString "PolarSSL Test CA" CA. Since Mbed TLS 2.14 (specifically ebc1f40aa008f6a2ba42e7436e4596d8f780b612 merged via https://github.com/ARMmbed/mbedtls/pull/1641), server2-sha256.crt is generated by Mbed TLS's own cert_write program, which emits a PrintableString. In older versions, this file was generated by OpenSSL, which started emitting UTF8String at some point. 4f928c0f374558ec352825061a399db7a37ca2fc merged via https://github.com/ARMmbed/mbedtls/pull/2418 fixed this for the SHA-1 certificate which was used at the time. The present commit applies the same fix for the SHA-256 certificate that is now in use. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-21 15:52:17 +02:00
MIIDNzCCAh+gAwIBAgIBAjANBgkqhkiG9w0BAQsFADA7MQswCQYDVQQGEwJOTDER
MA8GA1UEChMIUG9sYXJTU0wxGTAXBgNVBAMTEFBvbGFyU1NMIFRlc3QgQ0EwHhcN
MTkwMjEwMTQ0NDA2WhcNMjkwMjEwMTQ0NDA2WjA0MQswCQYDVQQGEwJOTDERMA8G
A1UEChMIUG9sYXJTU0wxEjAQBgNVBAMTCWxvY2FsaG9zdDCCASIwDQYJKoZIhvcN
Test that SHA-1 defaults off Added tests to validate that certificates signed using SHA-1 are rejected by default, but accepted if SHA-1 is explicitly enabled.
2017-05-09 15:59:24 +02:00
AQEBBQADggEPADCCAQoCggEBAMFNo93nzR3RBNdJcriZrA545Do8Ss86ExbQWuTN
owCIp+4ea5anUrSQ7y1yej4kmvy2NKwk9XfgJmSMnLAofaHa6ozmyRyWvP7BBFKz
NtSj+uGxdtiQwWG0ZlI2oiZTqqt0Xgd9GYLbKtgfoNkNHC1JZvdbJXNG6AuKT2kM
tQCQ4dqCEGZ9rlQri2V5kaHiYcPNQEkI7mgM8YuG0ka/0LiqEQMef1aoGh5EGA8P
hYvai0Re4hjGYi/HZo36Xdh98yeJKQHFkA4/J/EwyEoO79bex8cna8cFPXrEAjya
Regenerate server2-sha256.crt with a PrintableString issuer server2-sha256.crt had the issuer ON and CN encoded as UTF8String, but the corresponding CA certificate test-ca_cat12.crt had them encoded as PrintableString. The strings matched, which is sufficient according to RFC 5280 §7.1 and RFC 4518 §2.1. However, GnuTLS 3.4.10 requires the strings to have the same encoding, so it did not accept that the UTF8String "PolarSSL Test CA" certificate was signed by the PrintableString "PolarSSL Test CA" CA. Since Mbed TLS 2.14 (specifically ebc1f40aa008f6a2ba42e7436e4596d8f780b612 merged via https://github.com/ARMmbed/mbedtls/pull/1641), server2-sha256.crt is generated by Mbed TLS's own cert_write program, which emits a PrintableString. In older versions, this file was generated by OpenSSL, which started emitting UTF8String at some point. 4f928c0f374558ec352825061a399db7a37ca2fc merged via https://github.com/ARMmbed/mbedtls/pull/2418 fixed this for the SHA-1 certificate which was used at the time. The present commit applies the same fix for the SHA-256 certificate that is now in use. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2020-08-21 15:52:17 +02:00
HT4P6DSYW8tzS1KW2BGiLICIaTla0w+w3lkvEcf36hIBMJcCAwEAAaNNMEswCQYD
VR0TBAIwADAdBgNVHQ4EFgQUpQXoZLjc32APUBJNYKhkr02LQ5MwHwYDVR0jBBgw
FoAUtFrkpbPe0lL2udWmlQ/rPrzH/f8wDQYJKoZIhvcNAQELBQADggEBALVvYxsd
o5YSOIaApPlpnFUnz5zD/TbI9/63iJH+ae61jvpjTY1bqLBBEcqMMg9tVFUdt4xd
9MifL5zRZOGqKpfhWyoUZv7kXXMtfJsy0A6sqK11FcUE9r2Mt50tAO1MLZLJ5tKD
XY9/dTqXnENPxCGUo89/UwIFuNhKPUDBRMeyx8FaKsGVksF/lGxYVFWrfzZFlW0M
SXduk5xjoHE83erLEtZoxWIgrx7LXXgkDtswGkH+VpFt9dFFXJaeAQPeUBDAhEE9
UDkaCx5tPlyriwUW1w1xDx40VFV+Dgg9CFxiHCF+ppg+MG8HV0LVDRJlhN94QHNg
DAAVd5iuv8P+00Y=
Test that SHA-1 defaults off Added tests to validate that certificates signed using SHA-1 are rejected by default, but accepted if SHA-1 is explicitly enabled.
2017-05-09 15:59:24 +02:00
-----END CERTIFICATE-----
Reference in New Issue Copy Permalink