Topic: Letsencrypt - Dehydrated

[guest22]

Hi,

I need to add a domain to my Letsencrypt generated certificate. The domain is a sub-domain of mydomain.com, so 'sub.mydomain.com'. Dehydrated config and domains.txt are set ok (it works all for the main domain). http access to mydomain.com is SSL enforced. All following the wiki how-to. The apache config for the sub-domain is displayed here: https://wiki.contribs.org/Talk:Nextcloud

No when I add sub.mydomain.com to the domains.txt file, the verification of dehydrated for the sub-domain fails.

   + Responding to challenge for sub.domain.com...
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:unauthorized",
    "detail": "Invalid response from http://sub.mydomain.com/.well-known/acme-challenge/xxxxxxxxxxxxxx: \"\u003c!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\"\u003e\n\u003chtml\u003e\u003chead\u003e\n\u003ctitle\u003e403 Forbidden\u003c/title\u003e\n\u003c/head\u003e\u003cbody\u003e\n\u003ch1\u003eForbidden\u003c/h1\u003e\n\u003cp\"",
    "status": 403

The httpd error log shows:

  access to /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge/xxxxxxxx failed, reason: SSL connection required

Any idea how to trouble shoot this? It seems that a http request is done where only https is allowed.

TIA

[mmccarn]

Can you tell from /var/log/httpd/error.log where the response is being sought?

If so, you might be able to solve this with a hard link from the "real" source to the sub-domain source.

Or, I've seen some notes online about creating a universal 'alias' for apache to look for .well-know/acme-challenge at the same location for all domains & subdomains.

[mmccarn]

[edit] It looks like sub.domain.com requires authentication -- you may need to create a custom template fragment for this location, or disable the authentication for the source of the acme verification traffic.

[DanB35]

disable the authentication for the source of the acme verification traffic.

That's not going to be possible--Let's Encrypt expressly does not publish where their validation traffic is coming from, and has expressed an intent to further distribute it (perhaps via Tor, to give even more diversity).  Disabling authentication to .well-known/acme-challenge would work, as would using the DNS-01 challenge instead.

[ReetP]

Mine is all SSL only and works fine.

However you need to be a bit more crafty with your templates. Rocketchat demonstrates how to do this.

You need some lines in httpd.conf similar to this

    # Redirect Letsencrypt queries
    RewriteRule ^/.well-known/acme-challenge(/.*|$) https://%{HTTP_HOST}/.well-known/acme-challenge$1 [L,R]
    # Everything else goes to https/home
    RewriteRule ^/(.*|$) https://%{HTTP_HOST}/home [R,L]

In domains you need this:

your.subdomain.com=domain
    TemplatePath=ProxyPassForYourSubDomain


Then create a new template directory in /etc/e-smith/templates/etc/httpd/conf/httpd.conf

I copied over the existing ProxyPassVirtualHosts directory to ProxyPassForYourSubDomain

I then modified the standard ProxyPassContent template as follows for Rocket - note specifically the redirect Letsencrypt lines which are what you are after :

Code: [Select]

{
    use esmith::DomainsDB;
    my $db = esmith::DomainsDB->open_ro;
    my $d  = $db->get($virtualHost);
    my $t  = $d->prop('ProxyPassTarget');

    if ( $port eq "80" ) {
        $OUT .= "    # Redirect Letsencrypt queries\n";
        $OUT .= "    RewriteRule ^/.well-known/acme-challenge(/.*|\$) https://%{HTTP_HOST}/.well-known/acme-challenge\$1 [L,R]\n";
        $OUT .= "    # Everything else goes to https/home\n";
        $OUT .= "    RewriteRule ^/(.*|\$) https://%{HTTP_HOST}/home [R,L]\n";
    }

    if ( $port eq "443" ) {
        $OUT .= "    SSLEngine On\n";
        $OUT .= "    # Letsencrypt\n";
        $OUT .= "    ProxyPass /.well-known/acme-challenge/ !\n";
        $OUT .= "    # Websockets\n";
        $OUT .= "    ProxyPassMatch ^/sockjs/(.*)/websocket ws://localhost:3000/sockjs/\$1/websocket\n";
        $OUT .= "    # Everything else\n";
        $OUT .= "    ProxyPass / http://127.0.0.1:3000/\n";
        $OUT .= "    ProxyPassReverse / http://127.0.0.1:3000/\n";
    }
}

Job done

B. Rgds
John

[ReetP]

PS - this is how the webapps contribs basically does stuff and where I got the idea from. This is the manual method of doing the same thing.

[DanB35]

  access to /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge/xxxxxxxx failed, reason: SSL connection required

Rather than an outright 403 to non-https URLs, you should be redirecting them to HTTPS.  I'm not sure how you've done the SSL requirement; I'm pretty sure the normal way on SME does do a redirect.  And as already noted, requiring authentication to the path is going to mess things up as well.  It also seems odd--you require a username and password so they can get to the Nextcloud login screen, and enter the username/password again?  Is that really necessary?

[guest22]

Thanks all, still wrestling this.


I have no authentication set on apache level, just at application level. It seems that the redirect to https is not working somehow. Anyway, john is having a quick look. Will report back.

[guest22]

I think I have this resolved. I deleted the (manually added) db accounts key from the Primary ibay (and signal-event ibay-modify):

SSL=enabled

Certificates are now generated without any issue.