Bug #16652
closed
Certificate configured in DNS Resolver not shown as "In Use" if resolver doesn't have SSL/TLS enabled
Added by cemysce . 21 days ago.
Updated 20 days ago.
Description
I have a certificate (being maintained by acme 1.0.5 plugin, in case that matters). I use this certificate in the following 3 places within the pfSense config:
- System / Advanced / Admin Access: used as "SSL/TLS Certificate" under "webConfigurator"
- Services / DNS Resolver / General Settings: used as "SSL/TLS Certificate" under "General DNS Resolver Options" (note that "Enable SSL/TLS Service" is unchecked)
- Services / Acme Certificates / Certificates: it's one of the certificates ACME is maintaining
However under System / Certificates / Certificates, the "In Use" column only shows:
webConfigurator
Acme (1)
In other words, it is not showing that DNS Resolver uses the certificate if the DNS Resolver setting "Enable SSL/TLS Service" is unchecked. It does show it if it is checked. However, regardless of whether SSL/TLS is enabled, I think it is useful to list all the places the configuration references a given certificate. I suppose it depends on your definition of "in use" — the certificate is technically not being used by Unbound in my case, but it is still being used in the sense that it is being referenced by Unbound's configuration. I think it is more valuable to show all the places the certificate is referenced, because it's much more tedious and mistake-prone to download the config.xml file and figure this out manually.
I think the root problem here is the design of the DNS Resolver configuration UI. I am forced to select a certificate even if SSL/TLS is disabled. There is no "None" value for the "SSL/TLS Certificate" field.
Instead, I think the UI should hide the certificate field and not save its value to the config.xml, unless "Enable SSL/TLS Service" is checked.
- Status changed from New to Rejected
If SSL/TLS isn't enabled, then the certificate is not actively in use.
"None" is not a valid choice for a certificate field that requires a certificate. Forcing the user to pick that before they disable SSL/TLS is extremely awkward. Likewise, forgetting their choice of certificate if they temporarily disable SSL/TLS is not user-friendly.
A certificate being marked as "in use" cannot be removed. Making a user go and de-select a certificate that isn't actually being used by anything before allowing them to remove it, even though it just happens to have been selected at some point in the past but was later disabled, is much more user-hostile than the current behavior.
(Disregard my previous comment, which I deleted, I hadn't read your reply completely.)
The problem with the way it's currently working is that because the certificate is deemed to not be in use, I was able to delete the certificate in question even though a reference to it remained in the config.
It doesn't matter if there is a reference in the configuration, the dead reference doesn't hurt anything. If the user chooses to enable it again they can always pick a new certificate. If they load the page to enable SSL/TLS again, the field will default to whatever entry is first in the certificate list and the user can pick another one.
If SSL/TLS is disabled for a service, the selected certificate is irrelevant, you are not forced to choose anything explicitly, it can be ignored. The UI could hide the field, but that brings other complications like the ones I mentioned where it could forget the user's choice if they are disabling it temporarily.
Also available in: Atom
PDF
Updated by 
Updated by