Site with existing cert fails certbot & sabayon

Help
1

My domain is:
www.trymarketspace.com

I ran this command:
certbot certonly

It produced this output:
Failed authorization procedure
The client lacks sufficient authorization
Domain: www.trymarketspace.com
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
73f05368ac43935ebc2be7afc6781d29.56490cdbe84878026bf3b48a32352ffc.acme.invalid
from 50.16.239.64:443. Received certificate containing
’www.trymarketspace.com, trymarketspace.com, …

My operating system is (include version):
Ubuntu 14.04 (https://devcenter.heroku.com/articles/stack#cedar)

My web server is (include version):
Node.js, Express

My hosting provider, if applicable, is:
Heroku

I can login to a root shell on my machine (yes or no, or I don’t know):
no

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
Heroku admin

Details:

I have an existing production site on Heroku using an SSL Endpoint which uses an existing UCC SAN certificate from another vendor for a number of domains, most of which are owned by my clients, and it also uses a wildcard cert from another vendor. I would like to replace both of there with Heroku’s SNI implementation and a Let’sEncrypt cert.

I’m using Sabayon to generate the certificate and install it on Heroku. This process worked successfully on my staging dynos on heroku which didn’t have an SSL Endpoint. However on the production dynos, the Let’s Encrypt request failed both when I tried it through Sabayon (with an EOF error) and with certbot as described above.

One difference I can see between the two farms is that the production one already has a SAN certificate but the staging one did not. There are likely other infrastructure differences on the Heroku side.

I’m able to browse to the production site and successfully see the challenge response at URL /.well-known/acme-challenge/…

2

I’m not familiar with Sabayon or Heroku, but I can tell you that the TLS-SNI-01 challenge (certbot’s default) works by creating temporary TLS certificates and therefore needs the ACME client to be in control of the TLS endpoint. It does not use the /.well-known/acme-challenge/ URL.

You might have more luck with--webroot mode.

2 Likes
3

I tried with certbot and the --manual argument and successfully received a cert for 1 domain which is great.

Why would Sabayon be recieving an EOF from Let’sEncrypt?

4

Certbot shouldn’t have tried a TLS-SNI challenge unless it was either running standalone or apache mode.

The standalone mode is appropriate if there is no existing web server running on your machine, while the apache mode is appropriate if there is an Apache instance running on your machine. It seems like the first of these is true for your staging dyno, while neither is true for your production dyno; is that right? Did you somehow tell Certbot to use one of these modes? Does Sabayon run Certbot itself?

I would think that on the production dyno you would see Certbot fail with an error about port binding rather than allowing the certificate authority verification to proceed but then fail.

Some random hypotheses:

Could there be a copy of Apache installed on the production dyno that is not normally used (but that Certbot detected and tried to use for the authentication process)?

Could the existing web server on the production dyno be listening on port 80 but not 443?

Could the port that the web server on the production dyno thinks it’s listening on be different from the port that the public connects to it through?

5

Good thoughts @schoen.

I’m using Sabayon to get certs for both the production and staging environments, but it’s only working in staging. My staging environment does not have a Heroku SSL endpoint. My production environment DOES have a Heroku SSL Endpoint. Both environments are hosted on Heroku dynos so it’s very unlikely they have apache on them, as I believe Heroku give you a stripped down version of Ubuntu. My app is a Node.js + Express app.

Sabayon doesn’t use certbot itself - it’s entirely custom Golang as far as I can tell.

One thing I do know is that Heroku does request routing for SSL - My app runs on port 80 in both environments and Heroku forwards 443 from something like a web balancer. (I believe the the Heroku SSL Endpoint app is actually a load balancer). That’s the standard way to implement SSL on Heroku.

(BTW - The certbot --manual worked correctly as I’d seen it work before on other sites. I originally ran it accidentally without the --manual option)

6

It appears that this may be a bug in one of the dependant GO libraries:

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.