Validation failure using dehydrated client

[alavarre]

We’re trying to move from StartCom to LetsEncrypt.
The acme clients are problematic.
certbot has a host of dependency hells. We’ve tried a host of installs:
yast 2, ymp
pip install
git clone

All fail under openSUSE Leap 42.1

So now we’ve moved to trying dehydrated.

lukas2511/dehydrated

Installation is flawless, a breeze. But after setting up config, domains.txt and the requisite
/srv/www/htdocs//.well-known/acme-challenge/m4g1C-t0k3n

validation fails.

What should be the contents of m4g1C-t0k3n

???

Thanks in advance, Andy

Trace:

dehydrated -c -f /etc/dehydrated/config

INFO: Using main config file /etc/dehydrated/config

Processing genietvanhetleven.org with alternative names: www.genietvanhetleven.org

• Signing domains…
• Generating private key…
• Generating signing request…
• Requesting challenge for genietvanhetleven.org…
• Requesting challenge for www.genietvanhetleven.org…
• Responding to challenge for genietvanhetleven.org…
  ERROR: Challenge is invalid! (returned: invalid) (result: {
  “type”: “http-01”,
  “status”: “invalid”,
  “error”: {
  “type”: “urn:acme:error:unauthorized”,
  “detail”: "Invalid response from http://genietvanhetleven.org/.well-known/acme-challenge/ayKsDFHGqexArONrswdGo28hubFcBve_yTnAzyCXnmA: “\u003c?xml version=“1.0” encoding=“UTF-8”?\u003e\n\u003c!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”\n “http://www.w3.org/TR/xhtml1/D””,
  “status”: 403
  },
  “uri”: “https://acme-staging.api.letsencrypt.org/acme/challenge/zMk_lBVFt8qIydn3UnczCjQjIfXiVFbItuGa84Cytmk/25308019”,
  “token”: “ayKsDFHGqexArONrswdGo28hubFcBve_yTnAzyCXnmA”,
  “keyAuthorization”: “ayKsDFHGqexArONrswdGo28hubFcBve_yTnAzyCXnmA.GRKJbjyX7LV0xWrs1ckEcT4PIaByJvB-6Prmr4_lsYA”,
  “validationRecord”: [
  {
  “url”: “http://genietvanhetleven.org/.well-known/acme-challenge/ayKsDFHGqexArONrswdGo28hubFcBve_yTnAzyCXnmA”,
  “hostname”: “genietvanhetleven.org”,
  “port”: “80”,
  “addressesResolved”: [
  “70.186.159.22”
  ],
  “addressUsed”: “70.186.159.22”
  }
  ]
  })

[Osiris]

dehydrated should take care of the contents of the file, should be the token, a lot more of that garbage like the file name itself

Anyway, the fact your server returns a “HTTP 403 Forbidden” error sounds to me like there’s some kind of configuration problem: your current configuration of the webserver forbids Let’s Encrypt from reaching the token. Could this be the case? Some kind of restriction on the /.well-known/acme-challenge/ dir?

[danb35]

@alavarre

But after setting up config, domains.txt and the requisite /srv/www/htdocs//.well-known/acme-challenge/m4g1C-t0k3n

To be clear, you shouldn't be setting up m4g1C-t0k3n at all. Your server needs to be able to serve http://$YOURHOSTNAME/.well-known/acme-challenge/xxx, for any values of xxx, as a pure text file. And you need to tell dehydrated what filesystem path your webserver serves as .well-known/acme-challenge/. Dehydrated will create the file with the appropriate contents, and remove it when the challenge is completed.

[alavarre]

@alavarre

dehydrated -c -f /etc/dehydrated/config

Hello, thank both you for your replies.
Yes, the permissions were wrong, I fixed that. and
yes, each (vhost) has its own well-known/acme-challenge/ subdirectory.

Here is where we are:

We have gotten it working to the extent that we can generate keys and certs. However, openssl verify returns
> unable to get local issuer certificate

1. We set the staging CA in /etc/dehydrated/config

2. dehydrated -c -f /etc/dehydrated/config works fine. It creates
   /etc/dehydraterd/certs/ for each vhost and populates each with
   cert.pem
   chain.pem
   fullchain.pem
   privkey.pem

3. We then disabled staging and ran it again. Nothing changed: no new certs, all we got was
   ... Skipping renew!

4. The keys match the certs under the openssl x509 test.

5. But the certs fail under the openssl verify test:
   5.1 Tests of the two chain files fails with
   CN = Fake LE Intermediate X1
   5.2 Tests of the .pem file fails with
   unable to get local issuer certificate

6. Qualys reports:
   https://www.ssllabs.com/ssltest/analyze.html
   This server's certificate is not trusted, see below for details.

The remaining questions are:
Which/what/where is the proper CA cert to be used in openssl verify
Which/what/where is the proper CA cert to be used in /etc/apache2/vhosts.d/:
SSLCertificateChainFile
SSLCACertificatePath

Thanks again.

Best regards, Andy

============== Details ==============

1. We set /etc/dehydrated/config to the staging CA

'2. Ran
# dehydrated -c -f /etc/dehydrated/config
The key was to have all these transactions take place on the server machine! StartCom, from whence we came allowed you to do the dirty work on the local machine and transfer the results to the server. LetsEncrypt does not, it requires all the transactions to be on the server machine. Easy when you know how.

This indeed created subdirectories /etc/dehydraterd/certs/(vhost TLDR) for each vhost.

We then linked cert.pem, chain.pem, fullchain.pem, and privkey.pem to
/etc/apache2/ssl.crt/.pem
/etc/apache2/ssl.crt/_chain.pem
/etc/apache2/ssl.crt/_fullchain.pem
/etc/apache2/ssl.key/_key.pem

Finally we downloaded the letsencrypt X1, X3, and cross-signed X3 CA certs to /etc/dehydrated/certs/ and linked them to
/etc/apache2/ssl.crt

'3. Disabled staging and reexecuted. But noting changed. No new certs. No new results.

'4. We checked the keys against the certs; all work fine:
(openssl x509 -noout -modulus -in /etc/apache2/ssl.crt/(vhost TLDR).pem | openssl md5;openssl rsa -noout -modulus -in /etc/apache2/ssl.key/(vhost TLDT)_key.pem | openssl md5) | uniq

'5. We then try verifying the .pem against each of the chain and CA certs. These all fail.
Initially that was because we had set up staging, so the test returned CN = Fake LE Intermediate X1
We commented out the staging CA = line in /etc/dehydrated/config and reexecuted, but it didn't see anything to c.hange. The chain certs are still Fake LE Intermediate X1.

We then explicitly pointed /etc/dehydrated/config to
CA="https://acme-v01.api.letsencrypt.org/directory"
even though this is supposed to be the default. But no joy:

Rerunning, all we get is
Processing with alternative names: www.<(vhost TLDR)
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till May 10 18:21:00 2017 GMT (Longer than 30 days). Skipping renew!
There are no new certs and

• • openssl verify fails with CN = Fake LE Intermediate X1
    when using either of the chain files

• • openssl verify fails with unable to get local issuer certificate 
    

    when using any of the three CA certs, or when omitting -CAfile or when providing -CApath /etc/ssl/certs

'6. Qualys reports:
This server's certificate is not trusted, see below for details.
If trust issues are ignored: A
Server Key and Certificate #1
Trusted No

Thank you again for your time and help.

[danb35]

@alavarre

... Skipping renew!

That's because you had existing certs (even if untrusted certs) with more than 30 days' validity, so it won't renew them unless you add the -x flag--call dehydrated -c -x. That will force it to run the renew even though your certs are good for more than 30 days.

[alavarre]

Awesome. THANK YOU:

It worked:

It rebuilt all the certs, and now:

lavarre:/etc/apache2/ssl.crt # openssl verify -verbose -CAfile lets-encrypt-x3-cross-signed.pem genietvanhetleven.org.pem
genietvanhetleven.org.pem: OK

Woohoo!

So I shall use the cross-signed cert as CA cert… Tomorrow.
A great day. Thank you.

[danb35]

You’re welcome. Of course, you wouldn’t want the -x flag in your cron job, but it’s exactly the thing for this situation.

[alavarre]

Thank you all so much. Problem solved, all four vhosts performing correctly.

Learning points:

1. Dehydrated must be installed and run on the server Other systems let you use a local machine to get the certs and then move them to the (headless) server.
2. man dehydrated returns nothing
3. But this group and its accumulated selfless wisdom performs.

We are now free of StartCom and able to move on.

Thank you again. Well done, bien hecho, fato bene…

Marking this problem [SOLVED]

I’ve posted a synopsis of my experience in hopes that it may be of benefit to others:

Easy when you know how: Let's Encrypt open source "automated" TLS/SSL...

LetsEncrypt rocks. Thanks again.
Kind regards, Andy

[danb35]

@alavarre

Dehydrated must be installed and run on the server

Not necessarily; there are at least a few ways you could run dehydrated on a machine other than the one you're getting the cert for:

• You can use the DNS challenge
• You can arrange for the machine on which dehydrated is running to write to the web server's document root (e.g., by sharing that directory using something like SMB or NFS, or using sshfs)
• You can use the hook script feature to copy the challenge token to the suitable location on your web host (and to copy the certificate, chain, and key files to that server once obtained) -- I'm doing something like this for a few hosts on my LAN
• You can use a proxy to direct traffic for /.well-known/acme-challenge/ to the machine you're running dehydrated on

Probably others as well, but this is what comes to mind at the moment.

[alavarre]

All things are possible. It only depends on how much time you have to spend on it.

This works for me. Now, on to the leaking plumbing, broken sump pump, and furnace repair…

Thanks again for the help.

Cheers, Andy

[danb35]

@alavarre

All things are possible. It only depends on how much time you have to spend on it.

Certainly, and I'm not at all suggesting that you need to do any of the things I mentioned--just wanted to point out, in case you weren't aware, that there were/are a number of ways to use dehydrated to obtain certs without running on the machine you want the cert for.

[alavarre]

Thanks again. I’ll put it in my ditty bag for future reference.

Cheers, Andy