Koozali.org: home of the SME Server

Let's Encrypt error: Certificate authority doesn't allow certificate signing

Offline mikecoan

  • 9
  • +0/-0
Hi to all,

I am running SME Server 9.2.  A number of years ago I used the "manual" method to install dehydrated and obtain certificates for my domain and the mail host.  I don't believe the SME contrib for this existed.  The steps I followed seem to be the ones currently specified in the WiKI.  It worked flawlessly for years.  I did get a message about Let's Encrypt changing to V2 of the API.  I thought I fixed that by putting API="2" in the /etc/dehydrated/config  file.

My certificates expire on August 1.  When I run dehydrated -c -x I get the following message
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Aug  1 06:41:39 2020 GMT (Less than 30 days). Renewing!
 + Signing domains...
ERROR: Certificate authority doesn't allow certificate signing.

Naturally I would like to correct this error.  I am not averse to using the SME contrib, but I am not completely clear on what I have to remove from the manual method to return to the original state.  Do I remove the /etc/dehydrated/config and domains.txt files?  do I also remove the custom template?  What about the old certificates?

Perhaps there is a simple fix for the manual method.  Any suggestions would be appreciated. I checked the forums for similar problems, but did not see one.

Mike

Offline mmccarn

  • *
  • 2,626
  • +10/-0
Check the version of dehydrated on your server, in case your install process is preventing updates using 'yum'.

Here's what I get on a test server with a fresh install of smeserver-letsencrypt:

Code: [Select]
# yum install smeserver-letsencrypt --enablerepo=smecontribs
...
# rpm -qa dehydrated
dehydrated-0.6.5-1.el6.noarch

Offline mikecoan

  • 9
  • +0/-0
Dear mmccarn,

Thanks for the reply.  Unfortunately, rpm -qa dehydrated yields

dehydrated-0.6.5-1.el6.noarch

the same as yours.

Mike

Offline Stefano

  • *
  • 10,836
  • +2/-0
-Deleted-

« Last Edit: January 15, 2021, 07:45:16 AM by gzartman »

Offline mikecoan

  • 9
  • +0/-0
Hi Stefano,

smeserver-letsencrypt-0.5-15.noarch

As I mentioned in my original post, I used the manual method originally.  Maybe there is a conflict between smeserver-letsencrypt and what I did manually.  Should I just follow the steps in the WIKI for smeserver-letsencrypt?  Do I need to remove anything I did before before doing that, or will following the steps in the WIKI for smeserver-letsencrypt overwrite te steps and correct it?

Mike

Offline Stefano

  • *
  • 10,836
  • +2/-0
-Deleted-
« Last Edit: January 15, 2021, 07:45:02 AM by gzartman »

Offline mikecoan

  • 9
  • +0/-0
Stefano,

I removed letsencrypt and dehydrated, removed all my handwritten files, and then reinstalled letsencrypt and dehydrated contribs.  I followed all the steps, enabled test mode, and ran dehydrated -c.  I got the following error.

ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:ietf:params:acme:error:connection",
    "detail": "Fetching http://woodlawnfoundation.org/.well-known/acme-challenge/9WdoLkRdNdBTOoMJ77Mtm1PogVbD0DYi1otGx5OtTbQ: Connection refused",
    "status": 400
  },
  "url": "https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/85606385/InGEaw",
  "token": "9WdoLkRdNdBTOoMJ77Mtm1PogVbD0DYi1otGx5OtTbQ",
  "validationRecord": [
    {
      "url": "http://woodlawnfoundation.org/.well-known/acme-challenge/9WdoLkRdNdBTOoMJ77Mtm1PogVbD0DYi1otGx5OtTbQ",
      "hostname": "woodlawnfoundation.org",
      "port": "80",
      "addressesResolved": [
        "96.56.34.181"
      ],
      "addressUsed": "96.56.34.181"
    }
  ]
})


I will research the cause of that error, but if anyone has a fix that would be greatly appreciated.

Mike

Offline Stefano

  • *
  • 10,836
  • +2/-0
-Deleted-
« Last Edit: January 15, 2021, 07:44:42 AM by gzartman »

Offline mikecoan

  • 9
  • +0/-0
Further info.

The reason the challenge failed is because the webserver is not up.  The webserver is not up because in starting over I deleted the dehydrated directory.  That is where the existing certs were stored.  when I type config show modSSL I get

modSSL=service
    CertificateChainFile=/etc/dehydrated/certs/woodlawnfoundation.org/chain.pem
    TCPPort=443
    access=public
    crt=/etc/dehydrated/certs/woodlawnfoundation.org/cert.pem
    key=/etc/dehydrated/certs/woodlawnfoundation.org/privkey.pem
    status=enabled

Unfortunately, the chain.pem, cert.pem and privkey.pem files don't exist anymore.  I need to revert modSSL to its default which doesn't make reference to to those files.  I am looking for that file, but haven't located it yet.

Mike



Offline Stefano

  • *
  • 10,836
  • +2/-0
-Deleted-
« Last Edit: January 15, 2021, 07:44:29 AM by gzartman »

Offline mikecoan

  • 9
  • +0/-0
Stefano,

Thank you for your reply.  I know the standard entries for modSSL.  Unfortunately, when I installed manually I created a dehydrated-hook script that modified the standard modSSL file.  I see that the entrees in /db/configuration/defaults/modSSL are fine.  The problem is that on rebooting there is an error in /etc/http.conf/httpd.conf at line 133.

It says that /etc/dehydrated/certs/woodlawnfoundation.org/cert.pem does not exist of is empty and then the webserver fails to load.  Since the webserver does not start, it is not accessible and the challenge fails.  I need to find  what file to change so that config show modSSL reads

modSSL=service
   TCPPort=443
   access=public
   status=enabled

That is what is shown in the WIKI.  Somewhere in the templates lines are added to /etc/httpd/conf/httpd.conf that makes it look for these certificate files.  If I put in blank files for cert.pem.privkey.pem and chain.pem, the errors go away and the web site comes up.  dehydrated -c gives a new error

# INFO: Using main config file /etc/dehydrated/config
Processing woodlawnfoundation.org with alternative names: mail.woodlawnfoundation.org www.woodlawnfoundation.org
 + Checking domain name(s) of existing cert...unable to load certificate
140038517884744:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE

Not sure how to proceed at this point.  A trusted certificate was issued and now is no longer on the machine since I deleted the /etc/dehydrated directory when I began from scratch.  I thought I made a backup, but I only backed up the modSSL file.  The certicate expires August 1, so maybe when it expires and a trusted certificate no longer exists, the challenge will work.

Any thoughts are appreciated.

Mike


Offline Stefano

  • *
  • 10,836
  • +2/-0
-Deleted-
« Last Edit: January 15, 2021, 07:44:08 AM by gzartman »

Offline mikecoan

  • 9
  • +0/-0
Stefano,

Thank you. Thank you. Thank you.  All is well now.  I used the config delprop commands to get back to the start, deleted all the .pem files in /etc/dehydrated and reran dehydrated -c in test mode and got no errors.  I then ran dehydrated -c -c in production mode and got new certificates.  Thank you so much for your patience and perseverance.

Mike

Offline Stefano

  • *
  • 10,836
  • +2/-0
-Deleted-
« Last Edit: January 15, 2021, 07:45:51 AM by gzartman »

Online TerryF

  • grumpy old man
  • *
  • 1,821
  • +6/-0
A good outcome all round guys, thumbs up, with the first cutoff date now gone, increasing errors are going to effect anyone still on V1 certs, will be more than a few who were early users and had manual setups. Saving this post for future ref.

June 2020 they will stop allowing new domains to validate via ACMEv1.

Starting at the beginning of 2021 they will occasionally disable ACMEv1 issuance and renewal for periods of 24 hours, no more than once per month (OCSP service will not be affected). The intention is to induce client errors that might encourage subscribers to update to clients or configurations that use ACMEv2.

Renewal failures should be limited since new domain validations will already be disabled and we recommend renewing certificates 30 days before they expire.

In June of 2021 they will entirely disable ACMEv1 as a viable way to get a Let’s Encrypt certificate.
--
qui scribit bis legit