Topic: HTTP/1.1 405 Method Not Allowed error creating new Letsencrypt V2 certificate

[ldkeen]

Hi,
I did have Letsencrypt working on this server for quite a while but just today when it went to renew I started getting errors. In the end I removed it all and started from scratch but now I'm getting the error below:

+ Received 2 authorizations URLs from the CA
  + ERROR: An error occurred while sending get-request to https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/28154020 (Status 405)

Details:
HTTP/1.1 405 Method Not Allowed
Server: nginx
Date: Fri, 20 Dec 2019 09:46:22 GMT
Content-Type: application/problem+json
Content-Length: 103
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"

{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Method not allowed",
  "status": 405
}

[root@server dehydrated]# rpm -qa |grep dehydrated
dehydrated-0.6.2-14.el6.sme.noarch
[root@server dehydrated]# rpm -qa |grep letsencrypt
smeserver-letsencrypt-0.5-9.noarch


I have the latest version of Letsencrypt and dehydrated and an up to date SMEServer 9.2. Does anyone know how to fix this error. Not sure if it's related but I have recently installed SoftEther on this server (but I've installed that on others without any problems.

[ReetP]

Did you resolve this?

What are your letsencrypt settings? Looks like you are trying to use API2. When did you change from v1, and how?

[lurey]

hi,
I just tried to install "dehydrated" according wiki-page https://wiki.contribs.org/Letsencrypt/fr  (it's my first use of letsencrypt), and have same error :

+ ERROR: An error occurred while sending get-request to https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/32565757 (Status 405)

Details:
HTTP/1.1 405 Method Not Allowed
Server: nginx
Date: Mon, 13 Jan 2020 08:32:57 GMT
Content-Type: application/problem+json
Content-Length: 103
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"

{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Method not allowed",
  "status": 405
}

informations :

root@sme-xxxx #  config show letsencrypt
       letsencrypt=service
            ACCEPT_TERMS=yes
            API=2
           configure=none
           hookScript=disabled
           status=test
root@sme-xxxx #  rpm -qa |grep dehydrated
       dehydrated-0.6.2-14.el6.sme.noarch
root@sme-xxxx #  rpm -qa |grep letsencrypt
       smeserver-letsencrypt-0.5-9.noarch

...What is wrong ?
Thanks for help !

[mmccarn]

Searching "letsencrypt" plus the error text sent me to this discussion:
https://community.letsencrypt.org/t/problem-with-renew-certificates-the-request-message-was-malformed-method-not-allowed/107889/21

According to that discussion there have been updates to the letsencrypt server that require updates to the script (certbot or whatever) you're using to update certificates.

dehydrated is currently at v0.6.5 - https://github.com/lukas2511/dehydrated/blob/master/CHANGELOG, while the smeserver-letsencrypt contrib currently (1/13/2020) installs dehydrated v0.6.2

There is work in progress on getting dehydrated updated to the latest version:
* Bug 10812 - epel version of dehydrated
* Bug 10836 - force migration from acme-v1 to acme-v2

There is a note in the forum indicating you may be safe updating dehydrated from epel as long as you are not using any of the dehydrated hooks to distribute changes to other systems outside your SME server:
https://forums.contribs.org/index.php/topic,54106.msg282593.html#msg282593

[ReetP]

Yup - that is the problem.

You can use the updated SME version in smetest

DO NOT do a plain update or install from this repo - specific packages only.

yum --enablerepo=smetest install dehydrated

Should be dehydrated-0.6.5-1.el6.noarch.rpm

The continue in test mode until it all works.

It would be good if you tested the one in smetest and we can get it released.

https://bugs.contribs.org/show_bug.cgi?id=10836

You can also try the one from EPEL but it needs a few tweaks as some of the default locations have changed eg hook script  and cron that runs the script. Don't try unless you know what you are doing.

[lurey]

Hello mmccarn and ReetIP,
Thank you for these fast answords.

I did see this new version 6.5 in dev, but did not dare to try it without knowing  about its state of development.
You encourage me, I'll do it tonight (after work...).
Should I first uninstall version 6.2 ? and some - or all - files generated by its configuration?
If so, how do you make it "completely clean" before installing version 6.5?
Lot of thanks !

(N.B. I specify this is a first use for me, so there is no need to worry about renewal of an old certificate, or migration acme-v1 to acme-v2)

[ReetP]

I did see this new version 6.5 in dev, but did not dare to try it without knowing  about its state of development.

If it isn't working at the minute then the worst that will happen is it won't work after installation

Should be fine - just install as above and let us know please.

[lurey]

OK, I'll do it within a few hours.
 (...and I'll be happy if, despite a relative incompetence, my experience can be a useful test beyond my only case !).

I understand that I should try to upgrade to dehydration-6.5 without uninstalling anything from the last installation.
... Please, "shout" here before tonight  if that is'nt right !   

[ReetP]

OK, I'll do it within a few hours.
 (...and I'll be happy if, despite a relative incompetence, my experience can be a useful test beyond my only case !).

Best way to learn - we did!!

[qoute]
I understand that I should try to upgrade to dehydration-6.5 without uninstalling anything from the last installation.
... Please, "shout" here before tonight  if that is'nt right !   
[/quote]

Damn. Terry just reminded me that the version in smetest is actually the EPL version.

Hmmmm OK.

It is OK apart from it uses a different cron setup to do its daily checks.

If you install it over the top of what you already have you will just end up two crons but that's should be fine - we can resolve that !

Just test it and make sure - keep in test mode and you will be fine.

[lurey]

So,
1) update :

(...)
Mise à jour de     1 paquet(s)

Taille totale des téléchargements : 85 k
Est-ce correct [o/N] : o
Téléchargement des paquets :
dehydrated-0.6.5-1.el6.noarch.rpm                        |  85 kB     00:00
Lancement de rpm_check_debug
Lancement de la transaction de test
Transaction de test réussie
Lancement de la transaction
  Mise à jour   : dehydrated-0.6.5-1.el6.noarch                             1/2
warning: /etc/dehydrated/config created as /etc/dehydrated/config.rpmnew
  Nettoyage     : dehydrated-0.6.2-14.el6.sme.noarch                        2/2
(...)

# signal-event post-upgrade
# signal-event reboot

2) First try
#  dehydrated -c
gave an error :

(...)
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:ietf:params:acme:error:dns",
    "detail": "DNS problem: NXDOMAIN looking up A for mail.lurey.eu",
    "status": 400 

3) then disabled "mail.lurey.eu" in db and retry :
# dehydrated -c

# INFO: Using main config file /etc/dehydrated/config
Processing lurey.eu with alternative names: www.lurey.eu
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for lurey.eu
 + Found valid authorization for lurey.eu
 + Handling authorization for www.lurey.eu
 + Found valid authorization for www.lurey.eu
 + 0 pending challenge(s)
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!

     YES !

4)... BUT...
When I open www.lurey.eu and ask for certificate, it is the old- self produced- one !
(reconfigure + reboot does'nt change anything…)

[ReetP]

Your domains must be reachable via http:80

Are you still in test mode?

[lurey]

Your domains must be reachable via http:80

Yes, they are actually.

Are you still in test mode?

Yes, but with test mode,

(...)  You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However,  there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days"

it should have brought me a "test certificate", It is not at all the case ?

Well, I hope you are sleeping peacefully right now ... and I will do the same! Tomorrow will be another day...

[lurey]

Hello,

...the next day I received this message :

from : Cron <root@sme-lurey> test -s /etc/dehydrated/domains.txt && /usr/bin/dehydrated --cron
# INFO: Using main config file /etc/dehydrated/config
Processing lurey.eu with alternative names: www.lurey.eu
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Apr 12 17:09:22 2020 GMT (Longer than 30 days). Skipping renew!

I looked in /etc/dehydrated,


it looks like the certificate did arrive, but is not "installed"?

[ReetP]

it looks like the certificate did arrive, but is not "installed"?

Hard to tell as we don't know what has happened...... are you still in test mode?

On your server (or with a terminal or putty) do this:

Code: [Select]

config show letsencrypt
You can clean up old certs with:

Code: [Select]

dehydrated  --cleanup
For options do:

Code: [Select]

dehydrated -h
(-gc) (Move unused certificate files to archive directory)

Then look at this:

Code: [Select]

ll /etc/dehydrated/certs/lurey.eu
It should look similar to this:

Code: [Select]

total 32
-rw------- 1 root root 2106 Dec 16 13:17 cert-1576498657.csr
-rw------- 1 root root 2699 Dec 16 13:18 cert-1576498657.pem
lrwxrwxrwx 1 root root   19 Dec 16 13:18 cert.csr -> cert-1576498657.csr
-rw-r--r-- 1 root root 5925 Dec 16 13:18 certificate.pfx
lrwxrwxrwx 1 root root   19 Dec 16 13:18 cert.pem -> cert-1576498657.pem
-rw------- 1 root root 1648 Dec 16 13:18 chain-1576498657.pem
lrwxrwxrwx 1 root root   20 Dec 16 13:18 chain.pem -> chain-1576498657.pem
-rw------- 1 root root 4347 Dec 16 13:18 fullchain-1576498657.pem
lrwxrwxrwx 1 root root   24 Dec 16 13:18 fullchain.pem -> fullchain-1576498657.pem
-rw------- 1 root root 3243 Dec 16 13:17 privkey-1576498657.pem
lrwxrwxrwx 1 root root   22 Dec 16 13:18 privkey.pem -> privkey-1576498657.pem

You can check if apache is using your certs by doing:

Code: [Select]

grep pem /etc/httpd/conf/httpd.conf
Should see something like this:

Code: [Select]

SSLCertificateChainFile /etc/dehydrated/certs/lurey.eu/chain.pem
SSLCertificateFile /etc/dehydrated/certs/lurey.eu/cert.pem
SSLCertificateKeyFile /etc/dehydrated/certs/lurey.eu/privkey.pem


[ReetP]

Also note this:

+ Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Apr 12 17:09:22 2020 GMT (Longer than 30 days). Skipping renew![/i]

So it has checked the certs and they are OK and do not need renewing..... so it won't touch them.

[lurey]

After cleaning, here is what's left in /etc/dehydrated/certs/lurey.eu :

Code: [Select]

-rw------- 1 root root 1655 13 janv. 19:09 cert-1578938955.csr
-rw------- 1 root root 2216 13 janv. 19:09 cert-1578938955.pem
lrwxrwxrwx 1 root root   19 13 janv. 19:09 cert.csr -> cert-1578938955.csr
lrwxrwxrwx 1 root root   19 13 janv. 19:09 cert.pem -> cert-1578938955.pem
-rw------- 1 root root 1680 13 janv. 19:09 chain-1578938955.pem
lrwxrwxrwx 1 root root   20 13 janv. 19:09 chain.pem -> chain-1578938955.pem
-rw------- 1 root root 3896 13 janv. 19:09 fullchain-1578938955.pem
lrwxrwxrwx 1 root root   24 13 janv. 19:09 fullchain.pem -> fullchain-1578938955.pem
-rw------- 1 root root 3243 13 janv. 19:09 privkey-1578938955.pem
lrwxrwxrwx 1 root root   22 13 janv. 19:09 privkey.pem -> privkey-1578938955.pem
it's clearer ! (compared to your example, there is no < certificate.pfx > file...)

BUT...

Code: [Select]

grep pem /etc/httpd/conf/httpd.conf gives no answer !

...looking for "SSLCertificate" in httpd.conf gives :

Code: [Select]

[root@sme-lurey lurey.eu]# grep SSLCertificate /etc/httpd/conf/httpd.conf
SSLCertificateFile /home/e-smith/ssl.crt/sme-lurey.lurey.eu.crt
SSLCertificateKeyFile /home/e-smith/ssl.key/sme-lurey.lurey.eu.key
..editing conf-file, there are 3 lines :

Code: [Select]

# modSSL{CertificateChainFile} not set
SSLCertificateFile /home/e-smith/ssl.crt/sme-lurey.lurey.eu.crt
SSLCertificateKeyFile /home/e-smith/ssl.key/sme-lurey.lurey.eu.key
... tried to replace with :

Code: [Select]

SSLCertificateChainFile /etc/dehydrated/certs/lurey.eu/chain.pem
SSLCertificateFile /etc/dehydrated/certs/lurey.eu/cert.pem
SSLCertificateKeyFile /etc/dehydrated/certs/lurey.eu/privkey.pem
...restart httpd, and...  YES ! the LE "fake-certificat" (test-mode) is displayed for all my domains and subdomains !
I think, I found out at least wher "my" error is...

but this conf-file is made of templates.

Code: [Select]

# expand-template /etc/httpd/conf/httpd.conf
# /etc/rc7.d/S*httpd-e-smith restart ...and I lose my certificate again
"my" error is in "SSL Global Context Configuration" section, I think the 3 original lines comes from the two following templates
(in /etc/e-smith/templates/etc/httpd/conf/httpd.conf )
35SSL10SSLCertificateChainFile
35SSL10SSLCertificateFile

Is there a template (? custom) missing in my dehydrated/letsencrypt installation ?
I am not able to go further, nor to know, without the help of those who know the principles of this installation, if the error comes from my manipulations or from the installation script...

[ReetP]

You haven't answered the most important question.

That may give a clue what has happened.

Code: [Select]

config show letsencrypt
Also

cat /etc/dehydrated/config

For whatever good reason your post certificate generation script hasn't fired.

At a guess because you are still in test mode.

Please just answer the questions above and don't try messing about too much or you may make stuff a whole lot worse.

[lurey]

Hi,

Code: [Select]

[root@sme-lurey ~]# config show letsencrypt
letsencrypt=service
    ACCEPT_TERMS=yes
    API=2
    configure=none
    email=xxxxxxxxxxxxxx
    hookScript=disabled
    status=testI forgot to indicate it, because it hasn't changed since my first post !

Code: [Select]

[root@sme-lurey ~]# cat /etc/dehydrated/config
#!/bin/bash
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
CA="https://acme-staging-v02.api.letsencrypt.org/directory"

PARAM_ACCEPT_TERMS="yes"

I looked the templates, it looks like parameters "my $chain_file" , "my $crt" and "my $key" don't find value,
and then default value are set, as if there was no certificate.
for example, this is the code in template <35SSL10SSLCertificateChainFile > :

Code: [Select]

{
    my $chain_file = $modSSL{CertificateChainFile}
or return "# modSSL{CertificateChainFile} not set";

    $OUT = "SSLCertificateChainFile $chain_file";
}

[ReetP]

I forgot to indicate it, because it hasn't changed since my first post !

And that is exactly why I asked it because you have dived down rabbit holes that are not necessary and wasted a load of your time.

If you refer back to the documentation

https://wiki.contribs.org/Letsencrypt#Enable_Test_Mode

You will see that the instructions effectively say:

1. Install software
2. Run test mode to check certificates are correctly made
3. Change to 'enabled' to generate real certificates and deploy them

It will NOT deploy test certificates so you don't break your server. That is what TEST means.

So, if your test certificates all create correctly without errors then follow the documentation.

[lurey]

(...)
If you refer back to the documentation

https://wiki.contribs.org/Letsencrypt#Enable_Test_Mode

You will see that the instructions effectively say:

1. Install software
2. Run test mode to check certificates are correctly made

... it says precisely (before enabling product mode !):

If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority;  this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days.
.

I'll try to bee clearer... my problem is :
1) I tried to install "dehydrated" according wiki-page https://wiki.contribs.org/Letsencrypt/fr, with  dehydrated v0.6.2 (contrib 9 repo)
> in test mode, had the error that makes the tittle of this (older) thread, and posted I had the same.
2) with help and indications that I found here, I updated to dehydrated v0.6.5 (Devel 9 repo)
in mode test, had no more error, but...
could'nt verify, as said in the wiki (see above), the "fake certificate" delivered in test mode :
the auto certificate produced at the installation of SME was still shown, while everything shows (as you confirmed to me) that the LE-certificate is well generated.

That'is why I searched, why the well delivered (fake- because of test mode) certificat is not used, except handly modifying httpd.conf - but I'm sure, this is'nt the good way !

[ReetP]

You are tying yourself in knots here. You really need to go and read up and understand EXACTLY what is happening with the certificate generation process.

When you run test mode it tests to check the certificates can be correctly generated (it essentially just tests your domains and general setup), but they are fake certificates so will not be deployed to Apache because it can be difficult to revert them if you have an issue.

Yes, dehydrated 0.6.2 had an issue generating certs. Once you updated to 0.6.5 you no longer had the issue:

Code: [Select]

in mode test, had no more error, but
Exactly this. So it can generate a certificate but they are FAKE so will NOT be deployed.

If you generate the test certificates without errors as above you can then proceed to generate real certificates which the system will deploy. We DO NOT deploy fake certificates to use in Apache because they will cause problems with your server.

So if it CREATES (but does not DEPLOY) the test certs then do:

3. Change to 'enabled' to generate real certificates and deploy them

If the real generation completes correctly the system will deploy them to Apache. You do not have to touch anything.

[lurey]

Hello ReetP,
thank you for your patience...
I'm sorry if I asked questions and let you search because of bad reasons.
My misunderstanding comes from : what you explain me there, is different from what I understoud in the wiki:

Enable Test Mode
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers,
validate the hostnames you're requesting, and issue certificates. To do this, run

# dehydrated -c

If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal.
However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.

Also lower in the wiki page, under "Rush jobs / for the test"

Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.

If, as you explain to me, the fake certificat is not deployed, the above verification (try to connect to your server-manager page ...etc...) cannot be made.
However, I thought that this check HAD TO BE done and successfull before switching into production mode, that's why I was worried about not getting there...

Tonight back from work, I'll switch status to enable and run dehydrated -c -x , everything will be in order then !
Thank you for this help !

[ReetP]

I didn't think the test ones deployed, but it is so long since I wrote the contrib originally, and I now never bother testing the fake certs, that I forget.

I'll get someone to test.

[ReetP]

Your issue is that for whatever reason your config file is wrong.

It has no HOOK line so runs the wrong script.

Should look like this:

Code: [Select]

cat /etc/dehydrated/config

Code: [Select]

#!/bin/bash
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-know
n/acme-challenge"
BASEDIR="/etc/dehydrated"
CONTACT_EMAIL=admin@here.com
HOOK="/usr/bin/hook-script.sh"
API="auto"

PARAM_ACCEPT_TERMS="yes"
Try:

Code: [Select]

expand-template /etc/dehydrated/config
Then cat the file & paste here.

[lurey]

Hello ! 

You are (naturally) wright!
In production mode, the certificate is deployed.
logs ends in test mode with

Code: [Select]

(...for each challenge)
+ Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!IN prod mode, it adds :

Code: [Select]

(...)
 + Creating fullchain.pem...
Set up modSSL db keys
Signal events
All complete
 + Done!
I looked in httpd.conf, the three lines were automatically modified (as I had tested by hand to arrive to take into account the fake-certificate).

1°) My (?non-)problem is solved.
Thank you for your precious support !

2°) assuming that this is'nt due to my installation (with its stacked steps  )
...it would be usefull to report this modification in the wiki (unless you prefer to modify the installation to allow verification again at the test stage...).

EDIT : our posts crossed !!!

[lurey]

Code: [Select]

[root@sme-lurey ~]# cat /etc/dehydrated/config
#!/bin/bash
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
CA="https://acme-v02.api.letsencrypt.org/directory"
BASEDIR="/etc/dehydrated"
CONTACT_EMAIL=xxxxxx@xxxxxxx.fr
HOOK="/usr/bin/hook-script.sh"
API="2"

PARAM_ACCEPT_TERMS="yes"
!!! I can't tell you what caused this ordering ...
in /usr/bin with ls -l

Code: [Select]

-rwxr-xr-x 1 root root          691 13 janv. 09:31 hook-script.sh
13 jan 09:31 is my first installation (with older version 6.2)

/etc/dehydrated/hooks_deploy_cert.d/   is empty, I allways saw it empty ...

[lurey]

I tried re-switch test mode, (without running !)

Code: [Select]

[root@sme-lurey bin]# config setprop letsencrypt status test
[root@sme-lurey bin]# signal-event console-save
[root@sme-lurey bin]# cat /etc/dehydrated/config
#!/bin/bash
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
CA="https://acme-staging-v02.api.letsencrypt.org/directory"

PARAM_ACCEPT_TERMS="yes"

then switch again enabled mode :

Code: [Select]

[root@sme-lurey bin]# config setprop letsencrypt status enabled
[root@sme-lurey bin]# signal-event console-save
[root@sme-lurey bin]# cat /etc/dehydrated/config
#!/bin/bash
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
CA="https://acme-v02.api.letsencrypt.org/directory"
BASEDIR="/etc/dehydrated"
CONTACT_EMAIL=xxxxxx@xxxxxxx.fr
HOOK="/usr/bin/hook-script.sh"
API="2"

PARAM_ACCEPT_TERMS="yes"


No HOOK with test mode...

[ReetP]

Ahhh ok. Got it. Whilst lying in bed!!

That's a bug here:

cat /etc/e-smith/templates/etc/dehydrated/con
fig/10Default

It doesn't fix the hook script entry. It only adds in 'real' mode, not test mode.

I never noticed because the standard dehydrated script defaulted to /usr/bin so if there was no config item it was still correct.

With EPEL moving the hook script (why FFS??) this has revealed itself.

Please open a bug and I'll try and fix it later tomorrow.

If you want to test a solution....

Copy /etc/e-smith/templates/etc/dehydrated/con
fig/10Default to
/etc/e-smith/templates-custom/etc/dehydrated/con
fig/10Default

Edit and paste this at line 21

Code: [Select]

$OUT .= "HOOK=\"/usr/bin/hook-script.sh\"\n";
expand-template /etc/dehydrated/config

See if HOOK entry is there.

Ironically, if the certs are generated ok and you then go to 'normal' it will work !!

I might move hook script out so it is always there.

I'll look when I can.

[ReetP]

https://bugs.contribs.org/show_bug.cgi?id=10861

[ReetP]

Try the updated smeserver-letsencrypt version in smetest

Code: [Select]

yum --enablerepo=smetest install smeserver-letsencrypt
Should be 0.5-10

This should generate a HOOK line in test mode and deploy the test certificates.

Please try it and also paste a copy of your config.

[lurey]

hi,
You did work..!
I'll have time over the weekend to update and say what about.
I think I could also try a clean new installation on another machine, without any older version ...

I saw in bug 10861 that you are also working on the differences in cron (you did tell me that installing v6.5 would change or add something with cron, that I should have to worry about later). If I can (try to -) help spot things, tell me!

[lurey]

Try the updated smeserver-letsencrypt version in smetest

Code: [Select]

yum --enablerepo=smetest install smeserver-letsencrypt
Should be 0.5-10

I would like to be sure I understand ...
I installed with dehydrated package... it also installed smeserver-letsencrypt, and now, we update this one part, right?
(... which is not yet included in what could become as new dehydrated package...?)

[ReetP]

There are two separate packages.

Dehydrated itself contains the dehydrated script and some other bits & pieces like cron. 0.6.5-1 comes from upstream at EPEL.

smeserver-letsencrypt 'depends' on dehydrated. It won't install itself without the dehydrated rpm.

So you only need to update the smeserver-letsencrypt part, and then do a console-save to regenerate configurations.

smeserver-letsencrypt has templates and db keys to generate the correct configurations for the dehydrated script itself, and your server. It should generate /etc/dehydrated/config /etc/dehydrated/domain.txt and the cron file.

The bug was the logic that generated the config file.

I have just pushed 0.5-11 to buildsys which updates the cron entries as well. It should remove the old /etc/cron/daily/letsencrypt and add /etc/cron.d/dehydrated

The new package is waiting for signing but should be in smetest fairly soon.

So, run it in test mode and check the certs are deployed correctly using your browser and let me know.

[lurey]

hi !
First > thank you for these explanation, I understand a little better what I do... So,

- I updated smeserver-letsencrypt to v0.5-11.
- switched letsencrypt to test mode
following config :

[root@sme-lurey ~]# config show letsencrypt
letsencrypt=service
    ACCEPT_TERMS=yes
    API=2
    configure=none
    email=xxxxxx@xxxxxxx.fr
    hookScript=disabled
    status=test


[root@sme-lurey ~]# cat /etc/dehydrated/config
#!/bin/bash
CA="https://acme-staging-v02.api.letsencrypt.org/directory"
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
HOOK="/usr/bin/hook-script.sh"
BASEDIR="/etc/dehydrated"
CONTACT_EMAIL=xxxxxx@xxxxxxx.fr
API="2"

PARAM_ACCEPT_TERMS="yes"

- run
# dehydrated -c -x (with -x, otherwise nothing was done, since I already had a valid certificate.)

 > Then :
- runs normaly, ends without errors.
- "fake-certificate" deployed, can be seen as told in the wiki

- I returned to enabled mode
following config :

[root@sme-lurey ~]# config show letsencrypt
letsencrypt=service
    ACCEPT_TERMS=yes
    API=2
    configure=none
    email=xxxxxx@xxxxxxx.fr
    hookScript=disabled
    status=enabled


[root@sme-lurey ~]# cat /etc/dehydrated/config
#!/bin/bash
CA="https://acme-v02.api.letsencrypt.org/directory"
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
HOOK="/usr/bin/hook-script.sh"
BASEDIR="/etc/dehydrated"
CONTACT_EMAIL=xxxxxx@xxxxxxx.fr
API="2"

PARAM_ACCEPT_TERMS="yes"

All right, new (real) certificate is deployed.

[ReetP]

Yay !!

Thank you for your patiencr and for testing.

We'll release that soon.

[lurey]

About cron...
- I have a file
/etc/e-smith/templates/etc/cron.d/dehydrated/10dehydrated

Code: [Select]

{
    use strict;
    use warnings;
    use esmith::ConfigDB;

    my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");

    my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';

    if ( $letsencryptStatus eq 'enabled' ) {

        $OUT .= "#!/bin/sh\n\n";
        $OUT .= "32 3 * * 5 root test -s /etc/dehydrated/domains.txt && /usr/bin/dehydrated --cron";
    }

    else {
        $OUT .= "# letsencrypt is disabled\n";
    }
}

- there is no
/etc/cron.daily/letsencrypt

- in /etc/e-smith/templates/etc/cron.daily/letsencrypt/
there is one file <template-begin> ...that is empty

----------------------------------------------------------
to allow backup with dar, I wrote a file
/etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/43dehydrated

Code: [Select]

--go-into etc/dehydrated
should it be enough ...?

[brianr]

Got the warning message from letsencrypt yesterday.

Updated today from smetest and just run a "dehydrated -c -x" and  the cert has renewed just fine.

Well done guys!

[ReetP]

Got the warning message from letsencrypt yesterday.

Updated today from smetest and just run a "dehydrated -c -x" and  the cert has renewed just fine.

Well done guys!

Cool !!

There will be the template-begin but it is harmless and I will fix that.

Also need to update the cron etc. All in good time.