Importing Intermediate (Issuing) CA Certificates

[Fright]

Rather, I think it is a matter of needing good store management and minimum standards for application selection (I'm thinking of curl and the partial_chain option).

I have no idea how you can predict at what point developers of third-party applications will decide to change their behavior

When doing config, would there be any value to selecting certs from the store in a drop down list, e.g. how it works now when setting the Web GUI SSL Certificate...? Just the same for issuing CA certs when needed. Or is that how it is already implemented..?

sorry, did not quite understand the question. user selects the server certificate for application in GUI. if there are referenced CA's certificates in System: Trust: Authorities, the chain is built automatically and placed in the appropriate application directories

Does OPNsense core or HAProxy or nginix even do CRL checking or OSCP verification or stapling? Are any of these verification techniques default behaviour for OpenSSL (presuming that this or LibreSSL are what all of core and the plugins rely on), or would such checks need to be invoked deliberately...?

it's all on the app (nginx, for example, does not work with CRL distibuton points or some. CRLs are checked only if the file is explicitly specified). I do not think that the OPNsense should and in the right to do its work for the app.

How does one make the internal Root CA offline...?

Perhaps:

I think it's technically possible

Can CRLs for the internal Root CA still be published against the root CA certificate?

you can import CRL
but. if we are talking about best practices, then IMHO it is better not to use an internal opnsense CA in a production environment at all (for debugging and emergency use only). OPNsense is not a CA and does not try to seem like ..

[benyamin]

I have no idea how you can predict at what point developers of third-party applications will decide to change their behavior

Well obviously you can't predict such changes, but you can respond to them, even if the response is to recognise the problem and do nothing. For example, in the case of curl, an issue could be raised to assess curl's use of the partial_chain option. It might be determined that it does present a security issue that needs to be resolved, if say, a critical core or plugin function relies on curl and fully valid trust chains are expected. Or it might be determined that nothing should be done, but at least that decision is then documented.

When doing config, would there be any value to selecting certs from the store in a drop down list, e.g. how it works now when setting the Web GUI SSL Certificate...? Just the same for issuing CA certs when needed. Or is that how it is already implemented..?

sorry, did not quite understand the question. user selects the server certificate for application in GUI. if there are referenced CA's certificates in System: Trust: Authorities, the chain is built automatically and placed in the appropriate application directories

Yes, that was essentially my question. I did assume an interim step: that when required for any particular configuration, the issuing CA would be pre-populated in the relevant GUI field.

I've seen over the last several days that there is quite the mixture of different implementations. Are you aware of any OPNsense standard for plugin development is this space, or is it left up to the plugin dev to make these calls...?

I guess I see some value in trusting what is in the store to populate GUI fields and subsequent configurations. One feature I find notably missing in OPNsense is an indication of all places in the system where the certificates are in use. I think if something like that was implemented, then a system-wide framework for managing certificates would be more feasible. This would allow for the replacement of certificates in plugins before deleting expired or revoked certs from the store. Automated replacement of plugin certificates via, e.g. a wizard at System: Trust, would also be feasible.

Does OPNsense core or HAProxy or nginix even do CRL checking or OSCP verification or stapling? Are any of these verification techniques default behaviour for OpenSSL (presuming that this or LibreSSL are what all of core and the plugins rely on), or would such checks need to be invoked deliberately...?

it's all on the app (nginx, for example, does not work with CRL distibuton points or some. CRLs are checked only if the file is explicitly specified). I do not think that the OPNsense should and in the right to do its work for the app.

I agree in principle.

Provided the GUI exposes the functionality of the plugin to use such features (otherwise the novice may not be aware of the feature or be able to configure it). I note nginx has true OSCP validation and stapling capabilities built in. It is my understanding HAProxy relies on running a cron job to update files in a watch directory. I couldn't tell if OPNsense does external CRL or OSCP validation at all (with a preference for the latter). I would hope that it does.

If a cron job or daemon ran to check CRLs / OSCP validation of certificates in the OPNsense store at some reasonable (and configurable) interval, I see some benefit to a system-wide notification of invalid certificates being in use. Such a notification could be an alert to support personnel or even a watchdog process that can optionally shutdown plugins affected by revoked or invalidated certificates.

I think, if OPNsense should play any role in this space, the above would be it. If all plugins only make use of certificates in the OPNsense store, then this would mean any issues with certificate validity could be captured and acted upon.

An extension of this would be timely notifications for expiring certificates. :)

How does one make the internal Root CA offline...?

... but. if we are talking about best practices, then IMHO it is better not to use an internal opnsense CA in a production environment at all (for debugging and emergency use only). OPNsense is not a CA and does not try to seem like ..

Yes, clearly this would be the better practice. It is also somewhat dubious operating multiple CAs on the one system.  ;)

[benyamin]

One feature I find notably missing in OPNsense is an indication of all places in the system where the certificates are in use.

Just noticed a basic indication of where certificates are in use on the far RHS of the System: Trust: Certificates view.

If it could provide more info that would be awesome. Is the data available in the model?

[Fright]

but you can respond to them, even if the response is to recognise the problem and do nothing.

it will be even more confusing as the behavior of even familiar utilities will change. not to mention that it will be a nightmare for the maintainers imho (in addition to the lots of openssl options itself, each application has the right to introduce its own behavior)

One feature I find notably missing in OPNsense is an indication of all places in the system where the certificates are in use. I think if something like that was implemented, then a system-wide framework for managing certificates would be more feasible.

I think it will be too cumbersome (at least in terms of certs update automation from core) to ensure simplicity and stability. and if I understand the architecture correctly, devs quite clearly separates the core and plugins (plugins should not change the core behavior and the core should not spend too much on maintaining plugins. The main thing is to provide the infrastructure for work)

Just noticed a basic indication of where certificates are in use on the far RHS of the System: Trust: Certificates view.

yes. but only for core services. not plugins