Fingerprint suddenly not valid with Let's Encrypt?

[saphirblanc]

Hello,

This morning I found my cluster was not synced anymore.
I've recently replaced my 1 year certificate with Let's Encrypt.
Therefore, I wanted to know if the renewal process has something to do with this error ?

Thanks!

 

[Stoiko Ivanov]

Did you use PMG's Let's encrypt integration (available since PMG 6.4)?
If yes this error is unexpected (we added the updating of the fingerprints to the API calls which are used during certificate removal)

If not:
a) consider switching to PMG's integration
b) try running `pmgcm update-fingerprints`
(update-fingerprints is only available since PMG 6.4 - so you might need to update first)

I hope this helps!

 

[saphirblanc]

Hello,

Yes, I've used the one from PMG 6.4 however it's still marked as "standalone" under ACME, is this expected ?
Here is for the first server (main) :

I'll see how it will go during the next renewal.

Thanks.

 

[Stoiko Ivanov]

it's still marked as "standalone" under ACME, is this expected ?

Yes - 'standalone' here means the 'standalone' plugin - i.e. the http-01 challenge (as opposed to the dns-01 challenge where you need to config access details for your domain's dns-service

did running `pmgcm update-fingerprints` resolve the issue?

 

[saphirblanc]

Thank you for your answer.
I didn't know about `pmgcm update-fingerprints` and corrected the fingerprints in the cluster.conf on both servers. In case it's appearing again, I'll try.

 

[hk@]

Got the same issue here, but on two PMG7.2-4 models, they do LE fine, but fingerprints are not handled.
manually doing "pmgcm update-fingerprints" works, but is a bit annoying (giving the idea of putting this into cron real considerations)

any way to debug pmg-letsencrypt-renewals and the (obvisouly) not-working-fingerprint-syncing?

thx, hk

 

[Stoiko Ivanov]

Got the same issue here, but on two PMG7.2-4 models, they do LE fine, but fingerprints are not handled.

The ACME-integration of PMG should handle this automatically - (it gets called by the pmg-daily.timer)

 

[hk@]

after looking into the sourcecode I would agree it should be handled
yet the only log-entry in syslog I find looks like fingerprint changed and that's it...

Jan 24 02:19:35 pmgconfig[25552]: fingerprint 'E9:BE:AC:5F:EC:FA:D3:36:DB:31:4F:BA:C1:5E:61:1A:58:39:12:C2:AE:6D:B5:6E:C2:11:27:9A:DB:49:CA:5E' not verified, abort!
Jan 24 02:19:35 pmgconfig[25549]: end task UPID:000063D0:96E2CFE8:63CF3216:acmenewcert::root@pam: fingerprint 'E9:BE:AC:5F:EC:FA:D3:36:DB:31:4F:BA:C1:5E:61:1A:58:39:12:C2:AE:6D:B5:6E:C2:11:27:9A:DB:49:CA:5E' not verified, abort!

 

[Stoiko Ivanov]

The catch might be that update-fingerprints only works if there was not a change beforehand, which was not propagated ...
I'd manually fix the fingerprints this one time and would expect this to work

also make sure you're not having another ACME client (or anything else which touches you api-certificate) installed in parallel