Todo #9897
closed
Warn user when using incompatible ECDSA cert curves for WebGUI
Added by Viktor Gurov about 5 years ago.
Updated about 5 years ago.
Description
if you create ECDSA server cert ( https://redmine.pfsense.org/issues/9843 ) and set it to WebGUI HTTPS,
you got such error in browser:
SSL_ERROR_NO_CYPHER_OVERLAP
in system.log:
nginx: 2019/11/14 14:25:44 [error] 94513#100423: accept4() failed (53: Software caused connection abort)
pfSense 2.5.0.a.20191113.1759
- Assignee set to Jim Pingle
- Target version set to 2.5.0
It works fine with the right curve. Only prime256v1
and secp384r1
will work from our list with TLS v1.3. See c3cda38e0a091bca767a68889a390e00c129c73e
Though we probably need some way to warn the user about that.
- Tracker changed from Bug to Todo
- Subject changed from can't use ECDSA certs for WebGUI to Warn user when using incompatible ECDSA cert curves for WebGUI
- Affected Version deleted (
2.5.0)
- Status changed from New to In Progress
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Make central functions to check and test ECDSA compatibility. Issue #9843
Filter incompatible certificates from being offered for the GUI or Captive Portal. Implements #9897 - tested WebGUI and Captive, OK
Do the same for IPsec, which implements #4991 - tested, OK
Add a check for key type when generating ipsec.secrets to allow ECDSA certs to work in IPsec for issue #4991 - OK
Firefox/Opera/Safari also support secp521r1, but not IE/Edge/Chrome. see https://www.ssllabs.com/ssltest/clients.html
- Status changed from Feedback to Resolved
I didn't put secp521r1 on the HTTP list for that reason. If it isn't widely compatible, it's best not to recommend it. We can always add it later if those browsers change their minds. The fact that Chrome had it and then dropped it makes it more confusing, so I'd rather err on the side of not having people pick it thinking it will work.
Also available in: Atom
PDF