Invalid certificates? - Unable to locally verify the issuer's authority.

[danwashusen]

Hi! We've been using the role since 4.3 with good success. This morning I upgraded to v4.6 and kicked off the renewal process, as I've done several times before... However this time it appears the certificate is invalid (Ubuntu 20.04):

$ wget https://foo.bar.com/
--2020-12-03 16:02:49--  https://foo.bar.com/
Resolving foo.bar.com (foo.bar.com)... xxx.yyy.zzz.210
Connecting to foo.bar.com (foo.bar.com)|xxx.yyy.zzz.210|:443... connected.
ERROR: cannot verify foo.bar.com's certificate, issued by 'CN=R3,O=Let's Encrypt,C=US’:
  Unable to locally verify the issuer's authority.
To connect to foo.bar.com insecurely, use `--no-check-certificate'.

While trying to figure out what's wrong I noticed that the certificate chain appears to have changed:

Oddly Chrome/Brave is happy to open the certificate...

At this point I'm not sure its this role that's the cause of the issues but I thought I'd raise a ticket as it seems likely.

[danwashusen]

A bit more info; it seems like the Chromium derivatives (Chromem, Brave, Edge, etc) and our Windows GitLab runner are happy with the certificate. Firefox, ubuntu based GitLab runners, wget on MacOS all complain that the certificates are invalid.

My hunch at the moment is that the certificate chain created by the role is invalid.

[danwashusen]

The above commit 'fixes' the issue in my testing (where all new certificates were issued from the R3 chain). Although if LetsEncrypt changing their certificate chain is a thing, then maybe there is someway for the role to detect the change and handle it appropriately?

[mprahl]

Thanks for the contribution @danwashusen. The fix is released in v4.7.0.