Chained certificate handling in app-certificate manager is problematic.

[benoitg]

In the process of fixing #12, it became obvious that the de-facto api defined by https://github.com/clearos/app-certificate-manager isn't really future-proof.

The de-facto API in the certificate manager was clearly to support the old Apache style:

• $cert_files[$certificate]['certificate-filename'] (Corresponds to Apache SSLCertificateFile)
• $cert_files[$certificate]['key-filename'] (Corresponds to Apache SSLCertificateKeyFile)
• $cert_files[$certificate]['intermediate-filename'] (Corresponds to Apache SSLCertificateChainFile, which is deprecated in 2.4.8 https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile)

To which I added:

• $cert_files[$certificate]['fullchain-filename'] (Corresponds to Apache SSLCertificateFile for Apache >2.4.8, and many others: nginx, openfire, etc.)

It seems to me the certificate manager should expose a better API, not rely on the different apps sorting out what they need from keys that may, or may not be present.

Note that missing intermediate certificates by using cert.pem insteat of fullchain.pem causes especially hard to diagnose problems, where sometimes browsers work fine because they cached let's encrypt chains, but things like wget throw 'Unable to locally verify the issuer's authority.' or similar errors.

@pcbaldwin, @bchambers As discussed with ben this morning, I'd like to hear your thoughts on this, while relatively few apps use let's encrypt so far, and it's still time to abstract this out in the certificate manager. Ultimately this is a generic SSL issue, it just so happens that openfire exposed it first.

[pcbaldwin]

The Certificate Manager 3rd party certificates feature was glued on top mid-release and that caused all sorts of problems. For example, some certificate vendors will concatenate intermediate certs with customer certs (i.e. send a fullchain). That's okay, but some software barfs on this and users will often misconfigure things, e.g.:

myCertFile = fullchain (it's supposed to be just a cert)
myIntermediateFile = intermediate

The duplicate intermediate certificate is... not good. The Qualys SSL test doesn't like it either.

Postfix, Cyrus IMAP, OpenVPN, OpenLDAP, Zarafa/Kopano, Transmission, ProFTP, etc all have their SSL configuration methodologies. ClearCenter hasn't really reviewed the requirements for these packages yet, but I know that they'll run into some quirks! In the end, this all comes down to a resource issue. There are 25+ open requests in the ClearOS tracker for the Certificate Manager app, and limited resources to address them. Here are a couple of relevant open tasks:

• Detect embedded intermediate certs: https://tracker.clearos.com/view.php?id=17051
• Improved verification: https://tracker.clearos.com/view.php?id=16961

Basically, ClearCenter has to make sure 3rd party "certs" are not really "fullchains", clean those up, and then make sure the API returns what's needed for all the software packages listed above.

I'll bring this to the attention of ClearCenter and try to convince them to spend resources on this topic.