Unable to create Lets encrypt certificte

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
nextcloud.tecocllc.com

I ran this command:

sudo certbot certonly --manual --preferred-challenges=http --agree-tos --email webmaster@tecocllc.com -d nextcloud.tecocllc.com

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for nextcloud.tecocllc.com


NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?


(Y)es/(N)o: y


Create a file containing just this data:

8C3anfYrlA3AQ-EOspvo3DkLyOO_Olw0AJT5mP2YC7Y.zHiO1QPeI1WiU349D-iMGTyyqCVvLQPfqImxIZZfgDY

And make it available on your web server at this URL:

http://nextcloud.tecocllc.com/.well-known/acme-challenge/8C3anfYrlA3AQ-EOspvo3DkLyOO_Olw0AJT5mP2YC7Y


Press Enter to Continue
Waiting for verification...
Challenge failed for domain nextcloud.tecocllc.com
http-01 challenge for nextcloud.tecocllc.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: nextcloud.tecocllc.com
    Type: connection
    Detail: Fetching
    http://nextcloud.tecocllc.com/.well-known/acme-challenge/8C3anfYrlA3AQ-EOspvo3DkLyOO_Olw0AJT5mP2YC7Y:
    Timeout during connect (likely firewall problem)

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you're using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

My web server is (include version):

Server version: Apache/2.4.46 (Ubuntu)
Server built: 2020-08-25T12:13:38

The operating system my web server runs on is (include version):
uname -a
Linux ubuntu 5.8.0-1006-raspi #9-Ubuntu SMP PREEMPT Fri Oct 16 12:55:30 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

My hosting provider, if applicable, is:
Self, domain is from 'epik.com'

I can login to a root shell on my machine (yes or no, or I don't know):
Yes.

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No.

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot --version
certbot 1.7.0

Two things:

  • Do you really have to use the manual plugin for the http-01 challenge? Most often the system already has a webserver in place, so most users would use the apache or nginx plugin (depending on the webserver used) or if they don't want certbot messing with their webservers configuration file the webroot plugin.. The manual plugin isn't easily automatable, while the nginx, apache and webroot plugin are easily automatable.
  • I can't connect to your website too. You need to have at least port 80 open so the validation server can connect to your webserver and download the token to verify it.

Osiris,

I just setup this system, my preference is to use 'manual'. I actually did try using 'apache' plugin but that did not work. I then tried try using 'preferred-challenge=dns', and updating domain record with TXT info required, that did not work either. I have not tried 'webroot' approach, but I can try that and see if it works.

Website, nextcloud.tecocllc.com, is currently accessible with 'self-signed' certificate I previously installed. I had opened up Port 80, when I was trying to submit and create cert, but have since closed it.
When I create the, .well-known/acme-challenge file requested (when certbot pauses), I check if browser can access file, and it does, but then I hit Enter to allow script to Continue, then it fails. I have a log file (but I can't upload), new users.

Here is a few pages full of the last lines in log files.

2021-03-30 17:00:36,905:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/authz-v3/11957459428 HTTP/1.1" 200 1072
2021-03-30 17:00:36,908:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Tue, 30 Mar 2021 17:00:36 GMT
Content-Type: application/json
Content-Length: 1072
Connection: keep-alive
Boulder-Requester: 117282610
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: 0003OJMEP83Jvm57VYfwZqQcrI2devxCJHA3b8-0mS65Cww
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "identifier": {
    "type": "dns",
    "value": "nextcloud.tecocllc.com"
  },
  "status": "invalid",
  "expires": "2021-04-06T15:30:22Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:ietf:params:acme:error:connection",
        "detail": "Fetching http://nextcloud.tecocllc.com/.well-known/acme-challenge/8C3anfYrlA3AQ-EOspvo3DkLyOO_Olw0AJT5mP2YC7Y: Timeout during connect (likely firewall problem)",
        "status": 400
      },
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/11957459428/ki3Q8g",
      "token": "8C3anfYrlA3AQ-EOspvo3DkLyOO_Olw0AJT5mP2YC7Y",
      "validationRecord": [
        {
          "url": "http://nextcloud.tecocllc.com/.well-known/acme-challenge/8C3anfYrlA3AQ-EOspvo3DkLyOO_Olw0AJT5mP2YC7Y",
          "hostname": "nextcloud.tecocllc.com",
          "port": "80",
          "addressesResolved": [
            "68.101.144.181"
          ],
          "addressUsed": "68.101.144.181"
        }
      ],
      "validated": "2021-03-30T17:00:26Z"
    }
  ]
}
2021-03-30 17:00:36,908:DEBUG:acme.client:Storing nonce: 0003OJMEP83Jvm57VYfwZqQcrI2devxCJHA3b8-0mS65Cww
2021-03-30 17:00:36,910:WARNING:certbot._internal.auth_handler:Challenge failed for domain nextcloud.tecocllc.com
2021-03-30 17:00:36,911:INFO:certbot._internal.auth_handler:http-01 challenge for nextcloud.tecocllc.com
2021-03-30 17:00:36,912:DEBUG:certbot._internal.reporter:Reporting to user: The following errors were reported by the server:

Domain: nextcloud.tecocllc.com
Type:   connection
Detail: Fetching http://nextcloud.tecocllc.com/.well-known/acme-challenge/8C3anfYrlA3AQ-EOspvo3DkLyOO_Olw0AJT5mP2YC7Y: Timeout during connect (likely firewall problem)

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.

Would you be able to check from somewhere else on the Internet? From the error, it seems likely that you can access it from your own network, but that for some reason the rest of the Internet still can't access it.

Actually a couple of hours back, I was at a Cafe and was able to access nextcloud.tecocllc.com from internet. I am at home now. I will connect to my phone (hotspot) and connect that way.

I am able to access, nextcloud.tecocllc.com, via internet, currently accessing through phones mobile network.

I can't connect to it either. You might want to check your local hosts file to make sure you don't have it set locally.

1 Like

You can also try sites like Nextcloud.tecocllc.com - Is Nextcloud Down Right Now? and/or nextcloud.tecocllc.com down? Current problems and status. to check if it's open or not.

Sometimes there are regional firewalls in play, so it even looks up from a device "close" to the server, while the rest of the world can't connect.

I did a fresh install of nexcloud.tecocllc.com this morning, and retested, from external network. I did remove a '/etc/host' entry I had for internal host. I then tested external access using http:// and https:// and both the sites are accessible using both protocols (I am on the sites right now). BUT when i tested from the external access using test sites provided, the site is shown as down, using http and https protocols ( I am not sure why), Nextcloud.tecocllc.com - Is Nextcloud Down Right Now? and nextcloud.tecocllc.com down? Current problems and status. , I just clicked on link provided so I am not sure which protocol is used.

I did configure nextcloud to accept domain I am using, (tecocllc.com) as a "trusted" domain, maybe that may have something to do with accessible being allowed from my browsers. Additionally, previously I had configured my browser to view my self-signed Intermediate CA as trusted, on both browsers I tested (Brave and Chrome). I am not sure it matters though, since I was using 'certbot' from command line, and it was failing, I am still at a loss, as to why 'certbot' has failed for me. Any additional suggestions?

Hi @pmelendez,

The nextcloud.tecocllc.com is currently accessible for me, but it is generating HTTP 302 redirects to corresponding paths on http://tecocllc.com/, which is (1) a different server, (2) not accessible for me. It seems likely that, if you tried to get a certificate for the nextcloud subdomain in your current configuration, the Let's Encrypt validator would follow this redirect.

Currently tecocllc.com (which I can't connect to) resolves to 68.101.144.181 for me, the same address that the Let's Encrypt validator failed to connect to before. By contrast, nextcloud.tecocllc.com resolves to 88.214.207.96.

It's OK to have subdomains pointing to different servers, but you do have to be careful about HTTP redirects and about which server you're running your Let's Encrypt client on.

@schoen, @Osiris @darnold Thank you all! I never did get 'preferred-challenge=http' working, but I did get 'preferred-challenge=dns' working. As always it was something simple - when I was creating my DNS TXT record, I was following the instructions provided by Certbot - Please deploy a DNS TXT record under the name
_acme-challenge.nextcloud.tecocllc.com with the following value, which I dutifully entered as such ....Well I needed to create the DNS TXT record with _acme-challenge.nextcloud" (no appended ".tecocllc.com", domain name). This had bit me before...Once I "corrected" DNS TXT record I was successfully issued a certificate.
@schoen - You probably caught me as I was changing my DNS records as I was trying to figure how to make it work. Thank you for your attention.

Now to automate it...anyone have a script for 'epik.com'? Or I will need to write my own.

I'm not sure if certbot shows this, but technically a FQDN ends with a period for the root zone. 99,9999% of times, this period is left out, because it's implied. However, when editing a DNS zone file, this period is important: with the period, most DNS zone editors will see the entry as a FQDN. But without the period, they'll see the entry as a subdomain relative to the zone files origin. So if you put the FQDN without the period at the end, most zone editors will add the origin at the end, so you'll end up with _acme-challenge.example.com.example.com, which obviously isn't going to work.

Solutions are either to add the period to the end of the FQDN or, which you did, make the entry properly relative to the zones origin.

Chances are very big you'd have to write it yourself. You could look at the acme.sh github repository if there's already a script there which you could rebuild.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.