Add method to get all the names from a certificate

[Geal]

Hi,
To integrate rustls in sozu, I'd need a way to get the common name and subject alternative names from a certificate, and apparently I should implement it on EndEntityCert. I opened a related issue in rustls.
If you're ok with this feature, I could work on a PR tomorrow.

[briansmith]

I'd need a way to get the common name and subject alternative names from a certificate, and apparently I should implement it on EndEntityCert

My understanding is that you need a way to extract all the domain names from the certificate, not all the names, is that right?

webpki doesn't use the subject common name for anything and in particular it doesn't try to validate it as a DNS name. I don't think it makes sense to add an API for extracting the common name considering this; imagine if the common name was something like "example.com"; if sozu exposed that to the application then the application might think the certificate is valid for "example.com" when it, in fact, isn't.

In any case, I've actually implemented this feature already in my private tree, for dNSName subjectAltNames. I expect to post it publicly here in January.

[Geal]

Right, I don't remember where I got the idea we would still use CN for domain name validation. I'll remember we only use SAN now. I'll wait for this your publication of this feature then, thanks! On Dec 28, 2017 01:19, "Brian Smith" <[email protected]> wrote: I'd need a way to get the common name and subject alternative names from a certificate, and apparently I should implement it on EndEntityCert My understanding is that you need a way to extract all the *domain names* from the certificate, not *all* the names, is that right? webpki doesn't use the subject common name for anything and in particular it doesn't try to validate it as a DNS name. I don't think it makes sense to add an API for extracting the common name considering this; imagine if the common name was something like "example.com"; if sozu exposed that to the application then the application might think the certificate is valid for "example.com" when it, in fact, isn't. In any case, I've actually implemented this feature already in my private tree, for dNSName subjectAltNames. I expect to post it publicly here in January. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#64 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHSAPYeLZ1EhqniFZBQquvIPuMbLo_aks5tEt6vgaJpZM4RN3ty> .

[briansmith]

@Geal It seems I already implemented this: https://docs.rs/webpki/0.18.0-alpha/webpki/struct.EndEntityCert.html#method.verify_is_valid_for_at_least_one_dns_name.

I guess your use case is similar to the one I implemented that feature for: You have a server that accepts connections from clients that authenticate with a client certificate. The configuration for the server provides a way to set which clients, named by DNS name, connections are to be accepted from. You want to know which of the given names the certificate was actually valid for, so that you can construct an HTTP header that contains those names.

Note that this is slightly different than what you asked for because it doesn't return all the names for which the certificate is valid; it only returns the subset of the input names for which the certificate is valid.

[Geal]

In my use case, I can have thousands of certificates, so going through each certificate and checking the name is quite slow (at least with openssl, I didn't check webpki's behaviour here). I have a trie-like structure in which I put in advance all the names of a certificate to look up the correct one, then do the real name check with that certificate. On Dec 28, 2017 06:18, "Brian Smith" <[email protected]> wrote: @Geal <https://github.com/geal> It seems I already implemented this: https://docs.rs/webpki/0.18.0-alpha/webpki/struct.EndEntityCert.html#method. verify_is_valid_for_at_least_one_dns_name. I guess your use case is similar to the one I implemented that feature for: You have a server that accepts connections from clients that authenticate with a client certificate. The configuration for the server provides a way to set which clients, named by DNS name, connections are to be accepted from. You want to know which of the given names the certificate was actually valid for, so that you can construct an HTTP header that contains those names. Note that this is slightly different than what you asked for because it doesn't return *all* the names for which the certificate is valid; it only returns the subset of the input names for which the certificate is valid. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#64 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHSAGNMWWh9DAgcms9Af5htHBEX-bUgks5tEySigaJpZM4RN3ty> .

[briansmith]

I have a trie-like structure in which I put in advance all the names of a
certificate to look up the correct one, then do the real name check with
that certificate.

In that case, you'd need a separate feature. I think such a feature would be useful but I can't prioritize implementing it myself right now. If you submit a PR I'll review it. Check out the implementation of verify_cert_dns_name(), specifically the way it uses iterate_names().

I think the most tricky part of the PR will be documenting the new feature. In particular, it's important that we document that the feature is not designed to be used as part of certificate validation.

[Geal]

alright, here's the PR. While writing it, I started to think about the API. I see a very explicit intent to prevent misuse. As you said, this new method must not be used to replace proper name validation.

But on the other hand, I think there's a need for some functions to get information from certificates, getting the names, the certificate authority that issued it, the validity period, etc.

Do you think those features could live in webpki, or would they belong to another crate?

[briansmith]

I started to think about the API. I see a very explicit intent to prevent misuse. As you said, this new method must not be used to replace proper name validation.

But on the other hand, I think there's a need for some functions to get information from certificates, getting the names, the certificate authority that issued it, the validity period, etc.

Do you think those features could live in webpki, or would they belong to another crate?

I think they belong in webpki. I think the needs of clients and servers are really pretty aligned when things are done the best way so I don't think it's good to separate these functions.

I filed #67 for exposing the validity period for a cert (chain), #68 for exposing the constructed certificate chain, #70 for providing some tools for constructing an "optimum" certificate chain, and #71 for creating an entire indexing system similar to what you've already done. In particular if you'd like to collaborate on the indexing system then we could work together to implement all these things in webpki.

[akuanti]

In any case, I've actually implemented this feature already in my private tree, for dNSName subjectAltNames. I expect to post it publicly here in January.

@briansmith do you have an ETA on this?

[Geal]

I'm planning to finish the work on this in the next 2 weeks, as I'm polishing sozu's rustls integration

[seguidor777]

Hi all!
Is there any method in wepki to extract the common name from the cert?