Hello, I'm trying to connect to a gRPC server that provides a self-signed certificate. However I'm getting the following error WebPKIError(CAUsedAsEndEntity). If I understand correctly WebPKI wants the CA to issue an end entity certificate instead of using just the self-signed CA cert itself. Unfortunately I don't control the server software that generates the certificate, so I was wondering if there is a way to allow a self-signed CA cert to be used as an End Entity cert?

https://github.com/briansmith/webpki/blob/0573c1ec3fa4da14d74b9c6ee52087b80dadf16e/src/verify_cert.rs#L234 (fwiw removing this line passes the validation of the cert and the connection happens on rustls tlsclient example)

Here is an example of the certificate used in case it helps: Thank you

-----BEGIN CERTIFICATE-----
MIICcTCCAhagAwIBAgIQDojMgC+HAukHYJZqAr1SpTAKBggqhkjOPQQDAjAwMR8w
HQYDVQQKExZsbmQgYXV0b2dlbmVyYXRlZCBjZXJ0MQ0wCwYDVQQDEwRkaXZhMB4X
DTIwMDEwNzEzMTcxNloXDTIxMDMwMzEzMTcxNlowMDEfMB0GA1UEChMWbG5kIGF1
dG9nZW5lcmF0ZWQgY2VydDENMAsGA1UEAxMEZGl2YTBZMBMGByqGSM49AgEGCCqG
SM49AwEHA0IABEp6UaeVXTezbuWdAxl9Bs3EAZIVjdrpBm1/ejz4tCy5exvLUl53
7xATtOHM0Ge1mQ2FqtckSBgGlh4n1EW7cvKjggEQMIIBDDAOBgNVHQ8BAf8EBAMC
AqQwDwYDVR0TAQH/BAUwAwEB/zCB6AYDVR0RBIHgMIHdggRkaXZhgglsb2NhbGhv
c3SCBHVuaXiCCnVuaXhwYWNrZXSHBH8AAAGHEAAAAAAAAAAAAAAAAAAAAAGHBMCo
AcOHBKwTAAGHBKwSAAGHBKwRAAGHBAqTFLWHBKwUAAGHEP3yBa9KDwAATsxq//6w
HRWHEP6AAAAAAAAATsxq//6wHRWHEP6AAAAAAAAAAEKD//7cLCmHEP6AAAAAAAAA
WAe7//7DpFuHEP6AAAAAAAAAAEIt//7LJ5KHEP6AAAAAAAAAWAXw//6dcH6HEP6A
AAAAAAAAQJm2//44NHwwCgYIKoZIzj0EAwIDSQAwRgIhAKsgfl5XCcFUF9SUKsZw
eHQX0p/gIn79PdzilaX7uodzAiEAivOYSZcPz7BtqHD+MIP2NopFL84b3yK+T/a+
ZueR0PE=
-----END CERTIFICATE-----

See #98 We have an end entity certificate that is doesn't have a "NULL" value for the parameters of the AlgorithmIdentifier--it is absent. Reading RFC 5754, it looks like this scenario needs to be covered by implementations:

The AlgorithmIdentifier parameters field is OPTIONAL. Implementations MUST accept SHA2 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA2 AlgorithmIdentifiers with NULL parameters. Implementations MUST generate SHA2 AlgorithmIdentifiers with absent parameters.

This is an easy enough fix to implement since we just need to add a few more .der files to cover the case when "NULL" is absent, like so:

# rsaEncryption
OBJECT_IDENTIFIER { 1.2.840.113549.1.1.1 }

and then run ascii2der on that.

Without this change, we see an UnknownIssuer error which bubbles up from the UnsupportedSignatureAlgorithm error.

Fix #64

I am not too happy about it yet, I'd like to remove the ToString implementation for DNSName, since there's a Into<&str> for DNSNameRef. Unfortunately, I have not been able to make the function return a vector of DNSNameRefyet. For reference, the code I'm currently trying to build is:

#[cfg(feature = "std")]
pub fn list_cert_dns_names<'a>(cert: &'e super::EndEntityCert<'a>)
                                   -> Result<Vec<DNSNameRef<'a>>, Error> {
    let cert = &cert.inner;
    let names = std::cell::RefCell::new(Vec::new());

    iterate_names(cert.subject, cert.subject_alt_name, Ok(()), &|name| {
        match name {
            GeneralName::DNSName(presented_id) => {
                names.borrow_mut().push(DNSNameRef(presented_id));
            },
            _ => ()
        }
        NameIteration::KeepGoing
    }).map(|_| names.into_inner())
}

But there's a conflict between the lifetime of name (created in iterate_names and passed to the closure) and the lifetime of the DNSNameRef returned as result.

Not for merge.

This adds a failing test for parsing an attestation certificate from a Yubico U2F device. I have not yet learned enough about webpki/ring internals to figure out where the problem is. I will keep working on it, but would appreciate assistance if anyone can help.

i want to calculate the length in bytes of a der encoded cert buried in a variable-length packet. by exposing the reader's byte position i hope to make it possible to read out the number of bytes consumed by the der parser.

see https://github.com/briansmith/untrusted/pull/8

Depends on, at least, https://github.com/briansmith/ring/pull/262.

The RSA-PSS tests imported from Chromium will need to be modified from expect-failure to expect-success.

One open question is whether to support SHA-1 as the MGF digest and/or whether to require the MGF digest algorithm to match the signature digest algorithm and/or whether to require the salt to be the length of the digest output. Certificates generated using Microsoft's tools only use SHA-1 with 20-byte salts.

Before this commit UnknownIssuer was emitted on any error of verifying the anchor to the certificate.

Now the most important error is returned. In particular, UnsupportedSignatureAlgorithm is returned on, well, unsupported signature algorithm.

I agree to license my contributions to each file under the terms given at the top of each file I changed.

We get

error: failed to run custom build command for `integritee-parachain-runtime v0.1.0 (/home/abrenzikofer/integritee-parachain/rococo-parachains/runtime)`                             
                                                                                                                                                                                    
Caused by:                                                                                                                                                                          
  process didn't exit successfully: `/home/abrenzikofer/integritee-parachain/target/release/build/integritee-parachain-runtime-40f60bc84f76a22c/build-script-build` (exit code: 1)  
  --- stdout                                                                                                                                                                        
  Information that should be included in a bug report.                                                                                                                              
  Executing build command: "/home/abrenzikofer/.rustup/toolchains/nightly-2020-10-25-x86_64-unknown-linux-gnu/bin/cargo" "-Zfeatures=build_dep" "rustc" "--target=wasm32-unknown-unk
nown" "--manifest-path=/home/abrenzikofer/integritee-parachain/target/release/wbuild/integritee-parachain-runtime/Cargo.toml" "--color=always" "--release"                          
  Using rustc version: rustc 1.49.0-nightly (ffa2e7ae8 2020-10-24)                                                                                                                  
    Compiling pallet-substratee-registry v0.7.1 (/home/abrenzikofer/pallet-substratee-registry)
  error: duplicate lang item in crate `std` (which `web_sys` depends on): `panic_impl`.
    |
    = note: the lang item is first defined in crate `sp_io` (which `frame_support` depends on)
    = note: first definition in `sp_io` loaded from /home/abrenzikofer/integritee-parachain/target/release/wbuild/integritee-parachain-runtime/target/wasm32-unknown-unknown/release/deps/libsp_io-e5cd4d276385c920.rmeta
    = note: second definition in `std` loaded from /home/abrenzikofer/.rustup/toolchains/nightly-2020-10-25-x86_64-unknown-linux-gnu/lib/rustlib/wasm32-unknown-unknown/lib/libstd-b1a48c309b5fbc76.rlib

  error: duplicate lang item in crate `std` (which `web_sys` depends on): `oom`.
    |
    = note: the lang item is first defined in crate `sp_io` (which `frame_support` depends on)
    = note: first definition in `sp_io` loaded from /home/abrenzikofer/integritee-parachain/target/release/wbuild/integritee-parachain-runtime/target/wasm32-unknown-unknown/release/deps/libsp_io-e5cd4d276385c920.rmeta
    = note: second definition in `std` loaded from /home/abrenzikofer/.rustup/toolchains/nightly-2020-10-25-x86_64-unknown-linux-gnu/lib/rustlib/wasm32-unknown-unknown/lib/libstd-b1a48c309b5fbc76.rlib

  error: aborting due to 2 previous errors

  error: could not compile `pallet-substratee-registry`

  To learn more, run the command again with --verbose.

reproduce:

git clone https://github.com/scs/integritee-parachain.git
git checkout webpki-upstream
# or, precisely the commit: 9a2e4cbde
cargo build --release
# build should work

now, include webpki in our pallet crate by switching to the webpki-debug branch here https://github.com/scs/integritee-parachain/blob/7a9bfdb5f862c99e7b22426f0d6e004bf7ad56b2/rococo-parachains/runtime/Cargo.toml#L11

cargo build --release 

will fail with the above error.

so, the changes causing the error are: https://github.com/scs/pallet-substratee-registry/commit/69a96ad2ed1db54ccf7f409bb6e6c1dba905a39b

In the end, we'll need alloc too, but I tried to isolate the issue as much as possible

This continues on the work from #65, and adds what seems to have been missing per the review:

• Added a test that a certificate that contains wildcards in its Subject Alternative Name list has the wildcard skipped when returning the list.
• I also changed the behavior for the test invalid_subject_alternative_names. Instead of returning a BadDER error because one name wasn't a valid DNSName, those names are just skipped instead.

Closes #64

72a3ad9d3c04e8fc226c03577d778c7e0741f366 made parsing serial numbers reject zero and negative serial numbers. There are a few such root certificates in mozilla's and debian's root certs:

subject= /C=EU/O=AC Camerfirma SA CIF A82743287/OU=http://www.chambersign.org/CN=Chambers of Commerce Root
serial=00
subject= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
serial=00
subject= /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2
serial=00
subject= /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
serial=00
subject= /C=EU/O=AC Camerfirma SA CIF A82743287/OU=http://www.chambersign.org/CN=Global Chambersign Root
serial=00
subject= /C=ES/O=Agencia Catalana de Certificacio (NIF Q-0801176-I)/OU=Serveis Publics de Certificacio/OU=Vegeu https://www.catcert.net/verarrel (c)03/OU=Jerarquia Entitats de Certificacio Catalanes/CN=EC-ACC
serial=-11D4C2142BDE21EB579D53FB0C223BFF
subject= /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
serial=00
subject= /C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions RootCA 2011
serial=00
subject= /C=JP/O=SECOM Trust Systems CO.,LTD./OU=Security Communication EV RootCA1
serial=00
subject= /C=JP/O=SECOM Trust Systems CO.,LTD./OU=Security Communication RootCA2
serial=00
subject= /C=JP/O=SECOM Trust.net/OU=Security Communication RootCA1
serial=00
subject= /C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
serial=00

These are technically incorrect and most are of questionable value, but aws.amazon.com roots to Starfield Class 2 Certification Authority and wordpress.com roots to Go Daddy Root Certificate Authority - G2.

Currently we don't provide access to the end-entity public key, so one cannot verify signatures (or do RSA decryption) using the public key. Thus, one can't implement TLS and other protocols on top of webpki.

Further, many IETF protocols and data formats use the common SignedData sub-structure for signed data. So, it would be useful to have access for SignedData and maybe parse_signed_data or some variant of it.

See @ctz's attempt at https://github.com/ctz/webpki/commit/7ac038109b98bd71e84abe2874f0b41ebe3d47bc

Hi, I got an BadDER error when use rust-tls to build non-web tls application. After investigation. I found the cause of BadDER is the DNS name *.b is not valid.

I've tried some format.

a.b -> legal
*.b  -> BadDER
*b -> BadDER
*.b.b -> legal

After check the code, I found it's was intentional. https://github.com/briansmith/webpki/blob/b481381e914de604df30b1be2fe72d938a5c0e57/src/name/dns_name.rs#L568-L572

May I know why it had this check or based on what specification？

Because I'm not the one who generate this certificate. if the DNS name is illegal or it has security issue, I think I need some evidence to convince others.

Thks

I need to implement a certificate check that also checks for revoked certificates with X.509 CRLs (RFC 5280). I would like to use webpki to do this. For the moment it would be enough if I can verify the certificate path of a X.509 CRL to the root CA. Basically I would like an implementation of `EndEntityCert::verify_is_valid_tls_server_cert(..)] where the EndEntityCert is a CRL.

• I saw some comments that support for CRL is planned but as far as I can see this is currently not supported. Is this correct?
• Maybe you are aware of another crate that supports this? x509-cert allows to parse RCL but the verification part is missing

Fixes: https://github.com/briansmith/webpki/issues/54

Introduce IpAddressRef, DnsNameOrIpRef and the owned type IpAddress.

Introduce a new public function verify_is_valid_for_dns_name_or_ip that validates a given host name or IP address against a certificate. IP addresses are only compared against Subject Alternative Names.

It's possible to convert the already existing types DnsNameRef and IpAddressRef into a DnsNameOrIpRef for better ergonomics when calling to verify_cert_dns_name_or_ip.

The behavior of verify_cert_dns_name has not been altered, and works in the same way as it has done until now, so that if webpki gets bumped as a dependency, it won't start accepting certificates that would have been rejected until now without notice.

Neither IpAddressRef, DnsNameOrIpRef nor IpAddress can be instantiated directly. They must be instantiated through the try_from_ascii and try_from_ascii_str public functions. This ensures that instances of these types are correct by construction.

IPv6 addresses are only validated and supported in their uncompressed form.

This is a proposed solution to #258 .

When the feature std is enabled, adds an unrecognized_extensions member to the Cert struct in the form of a HashMap

Modifies the remember_extenstions function to place the data from any unrecognized extension into that HashMap, with the extension ID as the key.

Due to apparent limitations of rust, I was unable to find a way to use the existing oid macro for the match expressions. (hence the addition of [allow(unused_macros)] for the oid macro.

Suggestions on how this could be made cleaner are appreciated.

As currently written, the remember_extension function only keeps track of extensions that are explicitly recognized and deemed useful. This leaves a user of the webpki APIs unable to access any of the other extensions in a certificate, even if they just want the raw data from the extension.

It would be useful to store the 'unrecognized' extensions in case the API user needed access to them

Example:

use std::io::BufReader;
use std::io::Cursor;
use webpki::DnsNameRef;

fn main() {
  let cert = br#"
-----BEGIN CERTIFICATE-----
MIIGjjCCBPagAwIBAgIUb+bHc5CRq+HMoqKgLJVpQgk4XcIwDQYJKoZIhvcNAQEM
BQAwOjE4MDYGA1UEAwwvMzBhNjllNTItNTg1Zi00MmQ5LTkwODEtODg0N2Q3YTRj
MzY5IFByb2plY3QgQ0EwHhcNMjIwNDE1MjIwODUxWhcNMjQwNzEzMjIwODUxWjBa
MRAwDgYDVQQIDAdzZXJ2aWNlMS0wKwYDVQQKDCQzMGE2OWU1Mi01ODVmLTQyZDkt
OTA4MS04ODQ3ZDdhNGMzNjkxFzAVBgNVBAMMDmJlZHdhcnMtYXBwLTEwMIIBojAN
BgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA5WSnWwJU7D4WX7rqwNwx1zTMZYON
AsOw6gr4sVvNYAEXy3dnQCkdCgBmF8GIrLNU/wF+Wh9LUL89FYpPxOhlgIz6r0X+
mm3lvB6LRtGxwR4fihXgFLxOYwYu3gkd3Ooq81be1k0YwY2X95F02/IcU89V8l0t
eYaxluJG6M+JMRNnKa/bdffjYcgWHslNbxBu1owNRjsl1cj5nd+LFJ9NNZQoxqzP
eH3uMAvoBCoyUtWoTCTwrt9KPYj8RJCFnJvj14Qz+9KFy0rEXg3ZoxBCnSDCfm1I
egtO/AlOGtGhCbrrse2G/miKL7hqZi8y9VTRIlD2mL3mnG4onfaWbYxjlIvqMtU+
4FtBYCv0cV3FZMs+mM+7fZT4e5rsBbZFQiQw8bZnX16xJ53+j21G50VKffMYaJ+H
X8kWDD+8F+LnM+xnbPBRSqDK0X0nZ2u3vCr60FuqeRlGc7LIWn6CvjAF1J8wWEW1
QNgf2fRTcthIHUFJMmBiBZX26X7DPHwSJcbBAgMBAAGjggJqMIICZjAdBgNVHQ4E
FgQUrKIfpWX4XCxxCQJDBqUb3sLTIPIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAw
ggIrBgNVHREEggIiMIICHoIONDYuMTAxLjIzNi4xMzWCPHB1YmxpYy1iZWR3YXJz
LWFwcC1kby11c2VyLTQ4NTExNDktMC5iLmRiLm9uZGlnaXRhbG9jZWFuLmNvbYJF
cHJpdmF0ZS1yZXBsaWNhLWJlZHdhcnMtYXBwLWRvLXVzZXItNDg1MTE0OS0wLmIu
ZGIub25kaWdpdGFsb2NlYW4uY29tggoxMC4xMTQuMC4ygj1wcml2YXRlLWJlZHdh
cnMtYXBwLWRvLXVzZXItNDg1MTE0OS0wLmIuZGIub25kaWdpdGFsb2NlYW4uY29t
hwQKcgACgj1yZXBsaWNhLWJlZHdhcnMtYXBwLWRvLXVzZXItNDg1MTE0OS0wLmIu
ZGIub25kaWdpdGFsb2NlYW4uY29tghkqLmIuZGIub25kaWdpdGFsb2NlYW4uY29t
gihuLWJlZHdhcnMtYXBwLTEwLmIuZGIub25kaWdpdGFsb2NlYW4uY29tgi9wdWJs
aWMtbi1iZWR3YXJzLWFwcC0xMC5iLmRiLm9uZGlnaXRhbG9jZWFuLmNvbYI1YmVk
d2Fycy1hcHAtZG8tdXNlci00ODUxMTQ5LTAuYi5kYi5vbmRpZ2l0YWxvY2Vhbi5j
b22CRHB1YmxpYy1yZXBsaWNhLWJlZHdhcnMtYXBwLWRvLXVzZXItNDg1MTE0OS0w
LmIuZGIub25kaWdpdGFsb2NlYW4uY29thwQuZeyHMA0GCSqGSIb3DQEBDAUAA4IB
gQAYB9J601i+WBGavpg4LHbUjN+YyIPSQnQIuWpNKQ5UHq0pdUPUZ4Any3/GbPuG
GhmwcH36MlIQXbVjqqx1gQCRpX0XMw0saXqvMCpZpFm2fyg4Q/6TKExzE4ehMfOC
N/eHGAERvsc1kByN+wVcvVqHaD36X2HpXNdhxlqoVUrcCsVCOkEyj6UYi5N1nAWV
mRaCOlCgd9i8i3CKFvKIMFZGJQOx3oVD8NTuucLwJRc7e7QNW+bvJ/JWv6U12+T1
gUOIn466qylvWvmF0V/C79L3oh7TppMYPb11IbOFzwicIJd69SotN37vQrW5xhtz
pBsiGqrNC+PeP4g9YIgAHiNDB/oTRCRbWbU6OJnc9MJO5GgieVnSsKMdAX28bKyw
RbSCrFMYVLCoZa8MF8MrO4n8HX9oCZFmre7Cp8HoWO0SGw92YIygSlMzzm1bniRf
BCzJNklNiqAKu+9HIUd6hMOSJlrkGxYTag5D6zRU/O8So23qi1Bn3gQykqj1JknD
b+k=
-----END CERTIFICATE-----
  "#;

  let reader = &mut BufReader::new(Cursor::new(cert));
  let certs = rustls_pemfile::certs(reader).unwrap();

  let cert = webpki::EndEntityCert::try_from(&*certs[0]).unwrap();

  let dns_name = DnsNameRef::try_from_ascii_str(
    "bedwars-app-do-user-4851149-0.b.db.ondigitalocean.com",
  )
  .unwrap();
  cert.verify_is_valid_for_dns_name(dns_name).unwrap();
}

Dump of the certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6f:e6:c7:73:90:91:ab:e1:cc:a2:a2:a0:2c:95:69:42:09:38:5d:c2
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: CN = 30a69e52-585f-42d9-9081-8847d7a4c369 Project CA
        Validity
            Not Before: Apr 15 22:08:51 2022 GMT
            Not After : Jul 13 22:08:51 2024 GMT
        Subject: ST = service, O = 30a69e52-585f-42d9-9081-8847d7a4c369, CN = bedwars-app-10
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (3072 bit)
                Modulus:
                    00:e5:64:a7:5b:02:54:ec:3e:16:5f:ba:ea:c0:dc:
                    31:d7:34:cc:65:83:8d:02:c3:b0:ea:0a:f8:b1:5b:
                    cd:60:01:17:cb:77:67:40:29:1d:0a:00:66:17:c1:
                    88:ac:b3:54:ff:01:7e:5a:1f:4b:50:bf:3d:15:8a:
                    4f:c4:e8:65:80:8c:fa:af:45:fe:9a:6d:e5:bc:1e:
                    8b:46:d1:b1:c1:1e:1f:8a:15:e0:14:bc:4e:63:06:
                    2e:de:09:1d:dc:ea:2a:f3:56:de:d6:4d:18:c1:8d:
                    97:f7:91:74:db:f2:1c:53:cf:55:f2:5d:2d:79:86:
                    b1:96:e2:46:e8:cf:89:31:13:67:29:af:db:75:f7:
                    e3:61:c8:16:1e:c9:4d:6f:10:6e:d6:8c:0d:46:3b:
                    25:d5:c8:f9:9d:df:8b:14:9f:4d:35:94:28:c6:ac:
                    cf:78:7d:ee:30:0b:e8:04:2a:32:52:d5:a8:4c:24:
                    f0:ae:df:4a:3d:88:fc:44:90:85:9c:9b:e3:d7:84:
                    33:fb:d2:85:cb:4a:c4:5e:0d:d9:a3:10:42:9d:20:
                    c2:7e:6d:48:7a:0b:4e:fc:09:4e:1a:d1:a1:09:ba:
                    eb:b1:ed:86:fe:68:8a:2f:b8:6a:66:2f:32:f5:54:
                    d1:22:50:f6:98:bd:e6:9c:6e:28:9d:f6:96:6d:8c:
                    63:94:8b:ea:32:d5:3e:e0:5b:41:60:2b:f4:71:5d:
                    c5:64:cb:3e:98:cf:bb:7d:94:f8:7b:9a:ec:05:b6:
                    45:42:24:30:f1:b6:67:5f:5e:b1:27:9d:fe:8f:6d:
                    46:e7:45:4a:7d:f3:18:68:9f:87:5f:c9:16:0c:3f:
                    bc:17:e2:e7:33:ec:67:6c:f0:51:4a:a0:ca:d1:7d:
                    27:67:6b:b7:bc:2a:fa:d0:5b:aa:79:19:46:73:b2:
                    c8:5a:7e:82:be:30:05:d4:9f:30:58:45:b5:40:d8:
                    1f:d9:f4:53:72:d8:48:1d:41:49:32:60:62:05:95:
                    f6:e9:7e:c3:3c:7c:12:25:c6:c1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                AC:A2:1F:A5:65:F8:5C:2C:71:09:02:43:06:A5:1B:DE:C2:D3:20:F2
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            X509v3 Subject Alternative Name: 
                DNS:46.101.236.135, DNS:public-bedwars-app-do-user-4851149-0.b.db.ondigitalocean.com, DNS:private-replica-bedwars-app-do-user-4851149-0.b.db.ondigitalocean.com, DNS:10.114.0.2, DNS:private-bedwars-app-do-user-4851149-0.b.db.ondigitalocean.com, IP Address:10.114.0.2, DNS:replica-bedwars-app-do-user-4851149-0.b.db.ondigitalocean.com, DNS:*.b.db.ondigitalocean.com, DNS:n-bedwars-app-10.b.db.ondigitalocean.com, DNS:public-n-bedwars-app-10.b.db.ondigitalocean.com, DNS:bedwars-app-do-user-4851149-0.b.db.ondigitalocean.com, DNS:public-replica-bedwars-app-do-user-4851149-0.b.db.ondigitalocean.com, IP Address:46.101.236.135
    Signature Algorithm: sha384WithRSAEncryption
         18:07:d2:7a:d3:58:be:58:11:9a:be:98:38:2c:76:d4:8c:df:
         98:c8:83:d2:42:74:08:b9:6a:4d:29:0e:54:1e:ad:29:75:43:
         d4:67:80:27:cb:7f:c6:6c:fb:86:1a:19:b0:70:7d:fa:32:52:
         10:5d:b5:63:aa:ac:75:81:00:91:a5:7d:17:33:0d:2c:69:7a:
         af:30:2a:59:a4:59:b6:7f:28:38:43:fe:93:28:4c:73:13:87:
         a1:31:f3:82:37:f7:87:18:01:11:be:c7:35:90:1c:8d:fb:05:
         5c:bd:5a:87:68:3d:fa:5f:61:e9:5c:d7:61:c6:5a:a8:55:4a:
         dc:0a:c5:42:3a:41:32:8f:a5:18:8b:93:75:9c:05:95:99:16:
         82:3a:50:a0:77:d8:bc:8b:70:8a:16:f2:88:30:56:46:25:03:
         b1:de:85:43:f0:d4:ee:b9:c2:f0:25:17:3b:7b:b4:0d:5b:e6:
         ef:27:f2:56:bf:a5:35:db:e4:f5:81:43:88:9f:8e:ba:ab:29:
         6f:5a:f9:85:d1:5f:c2:ef:d2:f7:a2:1e:d3:a6:93:18:3d:bd:
         75:21:b3:85:cf:08:9c:20:97:7a:f5:2a:2d:37:7e:ef:42:b5:
         b9:c6:1b:73:a4:1b:22:1a:aa:cd:0b:e3:de:3f:88:3d:60:88:
         00:1e:23:43:07:fa:13:44:24:5b:59:b5:3a:38:99:dc:f4:c2:
         4e:e4:68:22:79:59:d2:b0:a3:1d:01:7d:bc:6c:ac:b0:45:b4:
         82:ac:53:18:54:b0:a8:65:af:0c:17:c3:2b:3b:89:fc:1d:7f:
         68:09:91:66:ad:ee:c2:a7:c1:e8:58:ed:12:1b:0f:76:60:8c:
         a0:4a:53:33:ce:6d:5b:9e:24:5f:04:2c:c9:36:49:4d:8a:a0:
         0a:bb:ef:47:21:47:7a:84:c3:92:26:5a:e4:1b:16:13:6a:0e:
         43:eb:34:54:fc:ef:12:a3:6d:ea:8b:50:67:de:04:32:92:a8:
         f5:26:49:c3:6f:e9

Rustls get's hung up on the DNS:46.101.236.135 SAN entry. is_valid_dns_id fails on this entry because label_is_all_numeric is true.

OpenSSL handles this certificate just fine.

All postgres databases provisioned by DigitalOcean have this SAN entry in their certs. Should I report this to them as an issue, or is this something that should be addressed in webpki?