Does not receive live certificates from Let's Encrypt

[mabo1972]

Hi, I have two new VPS with BOA 3.2.2 installed. As described in the documentation I have deleted the "ssl-demo-mode. pid" file to get real let's encrypt certificates and performed an "octopus up-stable all force". However, I still get a demo certificate for the hostmaster site. When I certify for a Drupal 8.4.4 site I get the message "No proper IP provided by the frontend for server @server_master, using wildcard" in the DNS settings, however, no wildcard is used.

On two other vps I have exactly the same DNS configuration and it works. The only difference is that the working vps run under esxi and the non-working vps run under proxmox so kvm

No proper IP provided by the frontend for server @server_master, using wildcard

I have replaced the real domain with hostname `

[hosting_le] To stop the LE Certificate auto-renewals please create an empty ctrl file.	-	info
[hosting_le] Path to use for this site specific empty ctrl file: /data/disk/o1/tools/le/.ctrl/dont-overwrite-hostname.pid	-	info
[hosting_le] You could then replace existing cert with any other cert since it will be left here as-is forever.	-	info
[hosting_le] NOTE: On hosted Aegir service you need to contact your host support for further assistance.	3 s.	info
[hosting_le] Hmm.. For some reason cert_dir doesn't exist: /data/disk/o1/tools/le/certs/hostname	-	info
[hosting_le] I couldn't generate LE cert during this Verify procedure.	-	info
[hosting_le] It's normal while running a series of Verify sub-tasks during Rename/Migrate.	-	info
[hosting_le] But if this happens during standalone Verify, maybe permissions are incorrect.	-	info

[hosting_le] Let's abort the procedure here. Bye.

`

[zbombicz]

Hello, The same problem here. I have just installed two vps with BOA 3.2.2. After trying to apply LE certificates on my d7 websites (on both vps) it produces the same info massages on verify task as mabo1972 discribed, and the website is not accessible through https.

The info message at task log also appears: No proper IP provided by the frontend for server @server_master, using wildcard

How can I debug more deeply these tasks to find the problem source? Thanks guys,

Regards,

[thebennos]

I looked at the given paths. In /data/disk/o1/tools/le/certs/www.domain.com

should be the the certs and pem file and some symlinks to integrate it in the generated nginx config, but there are only some symlinks openssl.crt openssl.csr openssl.key openssl_chain.crt

These are symlinks. For example: openssl.csr is a symlink to cert.csr and this is a symlink to the real file, but this does not exits!

Looks like the complete SSL generation failed, because there are no SSL certificates files.

[mabo1972]

@thebennos @zbombicz Have you found a solution to this problem?

[omega8cc]

This message is normal and not related in any way to LE:

No proper IP provided by the frontend for server @server_master, using wildcard

[omega8cc]

Please make sure you have checked the Verify task log for details.

Make sure to expand all truncated lines with [hosting_le] prefix.

The longest line should provide detailed debug information to help you determine the source of the problem.

Usually it's because your have IPv6 records in your DNS, while the LE agent currently in use fails to restrict it's LE checks to IPv4, hence removing IPv6 lines from the affected domain name DNS should help.

[mabo1972]

Okay, I found the cause. In the /data/disk/o1/tools/le/letsencrypt. sh there is still the wrong entry.

LICENSE="https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf"

If I adjust the entry manually I get LE certificates valid for the pages. However, when I run an "octopus up-stable force" I get a self-signed certificate for the hostmaster site and the entry in letsencrypt. sh is outdated again. Where do I have to set the entry so that I get a valid certificate for the hostmaster site.

I'am not have disabled auto-updates with _SKYNET_MODE=OFF and I do the update according to the instructions.

[omega8cc]

That sounds weird, because we have forced this update a long time ago:

Default values

CA="https://acme-v01.api.letsencrypt.org/directory" LICENSE="https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf"

[Lowell20]

I've had to update this file recently also, I think it was a new BOA installation for me

On Thu, Mar 15, 2018 at 8:33 AM, Barracuda Team notifications@github.com wrote:

That sounds weird, because we have forced this update a long time ago:

Default values

CA="https://acme-v01.api.letsencrypt.org/directory" LICENSE="https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf "

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/omega8cc/boa/issues/1255#issuecomment-373376754, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF1afzGB9XDUFA8CVuXI6AeZmsn2sPkks5tem2lgaJpZM4SO6pi .

-- Lowell Johnson 715-579-9276 development - hosting - security - performance

[omega8cc]

Can you check this LICENSE line in the /var/xdrago/conf/letsencrypt.sh file on your system?

[Lowell20]

The LICENSE is the line that I had to update to get the certificates working

To

LE-SA-v1.2-November-15-2017.pdf

On Mar 15, 2018 8:45 AM, "Barracuda Team" notifications@github.com wrote:

Can you check this LICENSE line in the /var/xdrago/conf/letsencrypt.sh file on your system?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/omega8cc/boa/issues/1255#issuecomment-373380359, or mute the thread https://github.com/notifications/unsubscribe-auth/ABF1afUu015keYrDPY_w9-us0RiwXiYHks5tenBhgaJpZM4SO6pi .

[mabo1972]

Here are the entries from the /var/xdrago/conf/letsencrypt.sh

CA="https://acme-v01.api.letsencrypt.org/directory" LICENSE="https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf"

but in the /data/disk/o1/tools/le/letsencrypt.sh i had these entries

CA="https://acme-v01.api.letsencrypt.org/directory" LICENSE="https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf"

when i manually edit these i get valid certs for my sites but not for the hostmaster site. After a "octopus up-stable all force" the old entries are back in the /data/disk/o1/tools/le/letsencrypt.sh

[omega8cc]

I will double check if we have included the correct/updated letsencrypt.sh file in the Octopus stable tarball.

[omega8cc]

Yes, there is correct file included in stable.

[omega8cc]

Ah, found it. We didn't include that file before in the archive, and instead downloaded from static archive, and we apparently forgot to update it manually. We should automate this to keep this in sync. It was left for manual updates before in the fear that auto-update may introduce changes affecting/breaking existing installs.

satellite_child_b_letsencrypt() {
  leRoot="${_ROOT}/tools/le"
  leKeyJ="${leRoot}/tools/le/private_key.json"
  leKeyP="${leRoot}/tools/le/private_key.pem"
  leCrtPath="${leRoot}/certs/${_DOMAIN}"
  exeLe="${leRoot}/letsencrypt.sh"
  pthLe="${_ROOT}/backups/system/letsencrypt.sh"
  mkdir -p ${_ROOT}/backups/system
  chmod 700 ${_ROOT}/backups/system
  rm -f ${_ROOT}/backups/system/letsencrypt*
  curl ${crlGet} "${urlDev}/${_AEGIR_XTS_VRN}/letsencrypt.sh" -o ${pthLe}

[mabo1972]

Yea thats it! Thank you very much.

[mabo1972]

Sorry I think this should stay open for the milestones