Core: system/trust: Distinguish certificates with same common name

[jpawlowski]

In case there are multiple certificates with the same common name but with different settings (e.g. different SAN or key length/type), it is impossible to distinguish between them in any of the GUI views as there are simply multiple certificates to choose from. This results in a lot of try-and-error to find the correct certificate.

Either a dedicated custom certificate name shall be possible (or even mandatory, see the "small p" fraction) or at least one should be able to see the description field content in every view somehow (tooltip?). Simply adding the description to the line might be bad, depending on its length.

[AdSchellevis]

Hi @jpawlowski, are you planning to work on some of your requests as well?
They seem to stack-up rapidly....

[jpawlowski]

@AdSchellevis Not for the moment as I'm unfamiliar with model-view-controller concept as such. Tried to understand some of the code in OPNsense but never got it just easily. Lacking time for a deeper dive besides doing troubleshooting already (it s not my only opensource arrangement).

[mimugmail]

Trust Code is legacy code base like in pfsense. If it would be MVC I'd have already added this.
I don't know all the dependencies, but I could imagine a new text box when adding certs for password.
This would be noneditable an stored in config.xml. When downloading password is passed along the command.

[mimugmail]

https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/system_certmanager.php#L185

Password is static to null .. perhaps just add a if isset to a new field and use password, else set null

I'm quite sure your php skills are better than mine :) You want to try?

[jpawlowski]

Don’t mix up this report with another one about the password thing ;)

[AdSchellevis]

@jpawlowski

it s not my only opensource arrangement

If nobody would contribute, there probably wouldn't be any free software would there? It's good to realise that your free to create tickets, but for your wishes to progress it might need more then placing an order.....

[jpawlowski]

@AdSchellevis Having a side conversation with @mimugmail on twitter, I understood that the OPNsense team considers community feedback as valuable contribution to improve the product functionality and quality likewise.

It is not my intention to overload anyone with personal driven feature requests. Also, I want to point out that this is also not about offending someone nor somebody's work. Don't take this personal!
The _suggestions_ I had opened where direct findings during configuration work were I thought this might be a point to improve for other people as well.

I believe it is up to you maintainers to decide whether any feature request is valid or not, e.g. if it would actually improve the quality or feature set of the product, or if it would make it worse.
If you think my feature suggestions are invalid, it is absolutely your part to reject and close them. If you conclude the features may be useful to implement, keep them open for the future to be considered whenever it may fit in to any sprint.

It might even be me working on some of the suggestions at some point in time, I am not fully rejecting that. It is like I said, all of our times are limited and everyone is free to set priorities according to their own needs _and_ capabilities. I am simply not in the position to jump into creating code, the learning curve to dive into the code structure is fairly high and more than just a couple of hours, e.g. after one working day I would _not_ be fully up to speed. I am not a software developer at all and my company does not pay me for OpenSource contribution (unfortunately). To me, the way you describe your expectations seems a little unfair.

All I can offer right now is my time to identify and properly describe areas of work. If you think this is not of any value to the community and/or the product, let me know. I can surely put my efforts elsewhere easily. Should the descriptions be too short or unclear, please let me know your feedback for each of the reports and I will happily improve on it to make them more clear.

[AdSchellevis]

@jpawlowski fair enough, thanks for taking the time to explain your motivation. We're all busy indeed, as long as expectations match reality it's certainly fine by me.

(no offence taken by the way, just making sure we all understand the rules)

[johnaheadley]

Should this be closed?

In case there are multiple certificates with the same common name but with different settings (e.g. different SAN or key length/type), it is impossible to distinguish between them in any of the GUI views

Either a dedicated custom certificate name shall be possible or at least one should be able to see the description field content in every view somehow

At least for System > Trust > Certificates, all the above are true now.

• Name column shows custom name
• Distinguished Name column shows SANs
• In Use column displays the info button which allows you to see all details of cert, including key length/type

The only thing I can see to add here is that System > Trust > Authorities does not have the info button. What do you all think?

[AdSchellevis]

@johnaheadley I agree, if there's anything still missing, it's better to open a new issue with a precise description of what's missing.