-
Notifications
You must be signed in to change notification settings - Fork 757
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
ECC certificate server status not detected #5128
Comments
Looking at the track record of how the current logic landed via #2459 (which is likely the state you're looking for) and #2463, I'm doubting a bit if there's actually a valid reason to check for existence of "Digital Signature" and "Key Encipherment/Agreement" (which seems to originate from https://community.openvpn.net/openvpn/wiki/HOWTO#ImportantNoteonpossibleMan-in-the-Middleattackifclientsdonotverifythecertificateoftheservertheyareconnectingto ). It might be a best practice for OpenVPN, but if the question is "is this a server cert", these attributes aren't necessarily needed. @fichtner what do you think? |
Also reported here: https://forum.opnsense.org/index.php?topic=24153.0 @AdSchellevis I wasn't aware that the server flag was so specific to OpenVPN, at least the naming did not suggest it although it is for sure only used by OpenVPN at the moment. We should make a correct server flag and then maybe check for further constraints in OpenVPN itself (or ask for OpenVPN server suitability per optional flag? |
…() and id-kp-serverAuth according to rfc3280, for #5128
The workaround I used was manually editing the config.xml file to use the refid of the ecc cert and restarting the webgui service. The new cert is now in use, however any further edits to the systems/settings/administration page throw the same error of "certificate is not intended for server use" |
@AdSchellevis b9b6e3e make sense, thanks a lot! |
…() and id-kp-serverAuth according to rfc3280, for #5128
…() and id-kp-serverAuth according to rfc3280, for opnsense/core#5128 (cherry picked from commit b9b6e3e)
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
Describe the bug
ECC certificates, like the ones issued from Let's Encrypt, do not have "Key Encipherment" listed as a key usage. These certificates may have the appropriate extensions for being considered a server certificate (e.g.: TLS Web Server Authentication extended key usage), but they are not recognized as server certificates by OPNSense. In OPNSense 21.7, the lack of server certificate status prevents such certificates from being used for the Web GUI.
To Reproduce
Certificates and key material have been provided in the "Additional context" section.
Steps to reproduce the behavior:
/system_certmanager.php?act=new
The certificate will be marked as "CA:No, Server:No"
/system_certmanager.php?act=new
The certificate will be marked as "CA:No, Server:Yes"
The only appreciable difference between the two certificates is that one of them is lacking the "Key Encipherment" key usage extension.
Expected behavior
Both certificates should be marked as "CA:No, Server:Yes" because they have the TLS Web Server Authentication extended key usage extension.
Describe alternatives you considered
Screenshots
Relevant log files
N/A
Additional context
KEY.pem
GOOD.pem
BAD.pem
Environment
Reproduced on
OPNsense 21.1.8_1 (amd64, LibreSSL).
OPNsense 21.7 (amd64, LibreSSL).
The text was updated successfully, but these errors were encountered: