wikisuite / app-lets-encrypt Goto Github PK

The Certificate Manager's Certificate_Not_Found_Exception should be handled in the Let's Encrypt app. A user reported seeing an "ooops" error in webconfig -- that shouldn't happen.

By default, certbot keeps 1000 log files. At one a day this is nearly 3 years of daily logs. In certbot there is a configurable option, --max-log-backups, which can be used to specify how many logs to keep. Can this be exposed in the app-lets-encrypt interface, or as a halfway house, have a file like /etc/sysconfig/certbot and have a commented out OPTIONS="" line which can be hand edited with the options required (e.g. "max-log-backups 200") and have this file read as part of the cron job//usr/clearos/apps/lets_encrypt/deploy/renew where you could add:

if [ -f /etc/sysconfig/certbot ];then
. /etc/sysconfig/certbot
fi

and change the line:

RESULT=certbot renew --preferred-challenges http-01 --renew-hook "/sbin/trigger lets_encrypt" >/var/clearos/lets_encrypt/renew.log 2>&1

to

RESULT=certbot renew --preferred-challenges http-01 $OPTIONS --renew-hook "/sbin/trigger lets_encrypt" >/var/clearos/lets_encrypt/renew.log 2>&1

in the style of the old init functions

Let's Encrypt needs to connect back to the ClearOS machine on port 80 in order to run the verification process. On a ClearOS machine running as a gateway or on the public Internet, that's not a problem. However, many ClearOS systems are deployed as a standalone server on a local network. Let's Encrypt will not work without a port forwarding rule enabled. Gotcha: the same port forwarding rule needs to be enabled on renewals!

Before attempting to create a new Let's Encrypt certificate, check for standalone mode and/or connectivity problems.

Certbot will fail to provision a new certificate if HTTPS/port 443 is blocked. The provisioning process should temporarily open (and then close) this port if required.

Hi there!

I'm trying to install a couple of WikiSuite components including the lets-encrypt one but I keep having the following error:

Error: Package: 1:app-certificate-manager-2.4.20-1.v7.noarch (clearos-verified)
           Requires: app-certificate-manager-core = 1:2.4.20-1.v7
           Installed: 1:app-certificate-manager-core-2.4.21-1.v7.noarch (@clearos-updates)
               app-certificate-manager-core = 1:2.4.21-1.v7
           Available: 1:app-certificate-manager-core-2.4.5-1.v7.noarch (clearos)
               app-certificate-manager-core = 1:2.4.5-1.v7
           Available: 1:app-certificate-manager-core-2.4.20-1.v7.noarch (clearos-verified)
               app-certificate-manager-core = 1:2.4.20-1.v7

Seems there's a compatibility issue?

In the case where Let's Encrypt has not yet been initialized, the get_certificate_files() method should return an empty array instead of throwing a "folder not found" exception.

The current implementation of the ClearOS Let's Encrypt app makes use of the Apache web server. That's the primary use case for the Let's Encrypt today, but there are other use cases where this dependency is not needed:

• Webconfig only
• Openfire
• SMTP/IMAP (SSL integration is on the roadmap)

Note: only the Web Server API is pulled in as a dependency (i.e. app-web-server-core), not the full Web Server UI in webconfig. Regardless, there's no need to pull in all the extra Apache overhead if it's not needed.

Adding a certificate through the app (ver. 1.0.7-1 on ClearOS 7.4) does not seem to work. It gives this message: Requesting certificate... and keep spinning for ever!

There is a note in the installation page says:

If it doesn't take effect right away,
just use another browser (ex.: Firefox instead of Chrome)

I switched to Firefox and still the same problem, no certificate was generated.

Thank you.

The certificate renewal process is logged in /var/log/system, but it would be nice to also log certificate requests. This is especially helpful when reviewing Let's Encrypt rate limits - https://letsencrypt.org/docs/rate-limits/

On a ClearOs 7 Let’s encrypt was installed and running.

I un-assigned a certificate from a domain and deleted the certificate.
Since I locked in error loop when I try to access Let’s Encrypt certificate but also when I’m trying to access Web Server => Web Site => any individual.

I got a screen with:

Ooops!
Certificate not found.

Nothing else I can do.

I un-install, restarted and flushed any let’s encrypt file I could found and get access back.
As soon as I install back Let’s Encrypt App and create one certificate (no matter the domain) the error is back.

If you try to create a certificate, say for a Primary Domain imap.my_domain.com and put smtp.my_domain.com in the Other Domains box, the Webconfig fails throwing a warning:

Warning
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for imap.howitts.co.uk
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

Creating the certificate without any "Other Domains" works.

This looks like it is fallout from the TLS-SNI-01 challenge for Let's Encrypt being shut down for the moment because of security concerns. An updated version of certbot is being developed to mitigate the issue: https://community.letsencrypt.org/t/help-test-certbot-apache-and-nginx-fixes-for-tls-sni-01-outage/50207/32 but I think the issue should be tracked until the new certbot package becomes available in ClearOS.

External applications (e.g. Openfire) might need to know when a Let's Encrypt certificate has been renewed. The certbot tool provides a --post-hook flag that we can use to hook into the ClearOS event system.

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.

There has been a change to the /usr/clearos/apps/lets_encrypt/deploy/renew script and the RESULT line now includes the switch "--standalone". This means certbot will use its built-in webserver which is great if you have not set up and started a webserver. If you already have a running web server, this command will always fail as it cannot bind to port 80. It is, however, a great solution if you are not running a webserver.

I believe the certificate creation and renewal routines should be made to detect if the web server is running (or if anything is bound to port 80). If it is not it should use the --standalone switch. Otherwise it should not.

This is a pretty urgent issue as the last update appeared around 12th Feb (which may have been the one containing the change) so we are approaching the 30 day limit where existing certificates will begin to expire.

Wildcard support is coming to Let's Encrypt on February 27, 2018. There's one gotcha -- only the DNS validation protocol will be available:

Wildcard certificates will be offered free of charge via our upcoming ACME v2 API endpoint. We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time.

That means an end user will have to create a DNS TXT record for both creation and renewals. There are some plugins available to automate this for some providers (e.g. Amazon Route 53, DigitalOcean DNS). Integration with ClearCenter DNS should be possible though.

To investigate further.

There is a critical issue with certbot-0.31. If you create a certificate after updating to certbot-0.31, it will create a file /etc/letsencrypt/live/README. The webconfig then tries to look for certificates under /etc/letsencrypt/live/README such as /etc/letsencrypt/live/README/cert.pem as it is only expecting certificate folders in /etc/letsencrypt/live/, and then the webconfig gives an "Ooooops: Certificate not found."

A number of thoughts come to mind:
1 - the app could just trap the error and skip it
2 - the app could only search folders /etc/letsencrypt/live/ and not try to search regular files
3 - Dirty fix, but check of the existence of /etc/letsencrypt/live/README and delete it if it exists. This could even be put in the renew-hooks.

Note the README file does not appear to be created when a certificate is renewed with a line like:
certbot certonly --standalone --max-log-backups 200 --preferred-challenges http-01 --preferred-challenges http-01 -d example.com

So it seems to be on creation only.