Installation script does not anticipate Let's Encrypt failure

[gisforgabriel]

What is the problem?

Having used the Digital Ocean Marketplace app, I am having two issues with the installation script. They are not directly related - happy to open separate issues if it makes it easier to work with.

1. I seem to be stuck in a loop, which the installation script does not anticipate.

Steps to reproduce the problem:

I ran the installation script caprover serversetup and it generated an error when the Let's Encrypt certificate generation fails (Error 1107 and Some challenges have failed). I cannot re-run caprover serversetup because the script considers that it has succeeded and prevents further running of it:

You may have already setup the server with root domain: mydomain.com! Use caprover login to log into an existing server.

Then when I use caprover login, I get an error message (Something bad happened and Error: self signed certificate).

Visiting http(s)://captain.mydomain.com just loads a page saying Nothing here yet :/ and a link to the documentation. Visiting http(s)://mydomain.com:3000 loads nothing at this point.

I'd be happy to try to regenerate the certificates, but I could not see anything in the documentation for the CLI app. Can ACME certbot be called directly?

2. Clearer terminology would be helpful.

Steps to reproduce the problem:

When running the caprover serversetup script, you are asked for new CapRover password (min 8 characters). But when you run caprover login you are asked for a CapRover machine password and then a CapRover machine name, with whom the login credentials are stored locally and suggests captain-01. Maybe this is obvious to people with more experience, but given that at this point I have not provided a machine name, username or anything else yet, it was not for me.

Output of uname -a && lsb_release -a && free -h on your server:

Linux machine-name 4.15.0-159-generic caprover/caprover#167-Ubuntu SMP Tue Sep 21 08:55:05 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.6 LTS
Release:        18.04
Codename:       bionic
              total        used        free      shared  buff/cache   available
Mem:           985M        226M        311M        1.0M        446M        606M
Swap:            0B          0B          0B

[githubsaturn]

What's your environment? Are you using a VPS with a publicly available IP address or is it a local installation on a private network?

If it's a cloud hosted VPS, I suggest you just clear the config and try to set up again:

docker service scale captain-captain=0
rm -rf /captain
mkdir /captain
docker service scale captain-captain=1

This will remove all existing configs.

[gisforgabriel]

@githubsaturn Thank you, that helped. It was an old CAA DNS record which was blocking the Let's Encrypt certificate generation I think.

I would still suggest that if caprover serversetup errors at any point, then the config should be removed so that the user has a clean slate to start again with. I'm afraid that making a merge request is beyond my skillset.

If no one picks up on this, then I'll put a merge request in to add a note to https://github.com/caprover/caprover-website/blob/master/docs/get-started.md

[githubsaturn]

I would still suggest that if caprover serversetup errors at any point, then the config should be removed

This is the current intended behavior. I'm not sure what happened in your case. The only situation when caprover serversetup cannot be re-run is when the last step (Force HTTPS) gets enabled.

The process of serversetup is:

• Login (with default or custom password)
• Change domain
• Enable HTTPS
• Force HTTPS
• Change password

Did you override any configs? Like skipVerifyingDomains?

[gisforgabriel]

All I did was launch a new droplet with the Digital Ocean Marketplace app, and then run npm install -g caprover and caprover serversetup. So it should be as clean an install as possible.

[githubsaturn]

Hmm... that's weird. Force HTTPS only gets enabled if HTTPS has already succeeded.

https://github.com/caprover/caprover/blob/513b781038fb0d65cbd88bffd978deaa31482f28/src/user/system/CaptainManager.ts#L687-L695
I'll look into this.

[daxyonis]

I got the same error when doing the setup of CapRover on a Digital Ocean Droplet. I defined an A-record for my domain name to point to the droplet. However, I did not define a CAA record (as it is not mentioned in the docs). Could it be that a CAA record (such as example.com. CAA 0 issue "letsencrypt.org") is needed for LetsEncrypt to work ?

[daxyonis]

Here is a screenshot of the issue... I destroyed the droplet and created another one after having defined the CAA records but still got the same error:

[githubsaturn]

Does your root domain has CAA? If so, it's intended to fail because your root domain contains CAA for DNSSEC and your subdomain doesn't. It's a DNS feature and it's related to Let'sEncrypt. You can read more about it here: https://letsencrypt.org/docs/caa/#servfail

If you have further questions regarding this, Let'sEncrypt forums is a better place: https://community.letsencrypt.org/

Examples:

• https://community.letsencrypt.org/t/solved-dns-problem-servfail-looking-up-caa-for-mit42-de/20965
• https://community.letsencrypt.org/t/dns-problem-servfail-looking-up-caa/106841

[daxyonis]

Thank you for the link : I waited for an hour for the CAA record to take effect, I set it on my root domain and tested it using the command dig evkosoft.com caa : it returned no error. I then redid the caprover serversetup command, this time it worked ! I read here that a CAA record set on example.com also applies to any subdomain, like subdomain.example.com (unless overridden).