-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support client certificates that identify a person, not a server #209
Comments
Interesting! I didn't think this there was a big difference, At least in all cases I tested and where the certificates were X.509v3 it worked fine with the AllowAnyAuthenticatedClient from rustls. The only problem I ran into was when the client cert was X.509v1, which was supported by nginx and other servers using openssl, but not by my rustls server using webpki client certificate verification. |
You are just assuming that anybody with a valid certificate is authorized. If you needed more fine-grained access control then you'd see that more stuff is missing. It is probably true that V1 certificate support are probably needed for personal certificates. |
Ah yes. After the cert is verified with webpki, I use the x509parser crate to obtain the email address etc. it is issued to. It would be really awesome if I could use webpki to do the same in one go. |
The first step of this would be addressing #219. |
Why is v1 certificate support required for personal certificates? Is there common software or a popular CA that generate such certificates? |
From my experience a modern openssl will give you v1 certificates unless you explicitly enable any extensions. But I still think the goals of supporting v1 certificates and extracting/matching on the subject info should be two seperate goals, even though both are especially interesting for user certificates. |
It is maybe not so much "required" but if Directory Names are being used for validation then the Subject of the certificate is a valid Directory Name and so no extensions would be necessary according to X.509 rules, as a missing EKU means "any EKU" and likewise for most other "missing" extensions. Regardless, I intend to fix #219 very shortly now, before spending effort on this issue, so there's not much point in worrying about whether #219 strictly blocks this. I expect #249, about providing a configuration API, will block this. Which forms of names to accept would be a new configuration parameter. |
Now we don't have an API that lets a TLS server validate a user client certificate. So, for example, if I try to authenticate to a website using my smartcard that contains a certificate for my own person, the server cannot validate the certificate if it uses webpki for certificate validation.
This would probably require much better GeneralName support in webpki.
The text was updated successfully, but these errors were encountered: