I have got 2 files from LE but I need the SSLCertificateChain file as well, where do I get it from?

My domain is: gldn.page

The operating system my web server runs on is (include version):
ubuntu 20.04

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):
HestiaCP

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

My hosting provider, if applicable, is:
dedicated

Hi,
I have received a certificate from Let's encrypt for the above domain.
and got the message:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/gldn.page/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/gldn.page/privkey.pem
This certificate expires on 2022-09-05.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

The problem I have is that the CP I use ( HestiaCP ) rquires 3 files:

SSLCertificateFile /etc/letsencrypt/live/%domain%/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/%domain%/privkey.pem ;
SSLCertificateChainFile

What do I put in the last one?
It is asking for CA file/certificate.

Hope someone who knows HestiaCP can help out.

Thanks

1 Like

Hello again Dave, this topic should answer those questions
https://eff-certbot.readthedocs.io/en/stable/using.html#where-are-my-certificates

3 Likes

Note that SSLCertificateChainFile is deprecated since Apache 2.4.8. Are you absolutely sure you need it?

Weird... gldn.page seems to be running nginx and not Apache.. So I'm confused why you're asking questions about Apache configuration directives?

3 Likes

This is an ongoing saga. Dave probably needs to discuss with Hestia what they want on their Control Panel. Perhaps he could refer Hestia support to the certbot docs page I linked to so they can resolve it.

4 Likes

Hello,
Yes it has been a bit of a saga, but a progressive one!

Thanks for your replies - they are helpful in leading me towards
an understanding of how Hestia works.
And how I can make it play with LE for wildcard subdomains.

HestiaCP uses BOTH nginx and apache2

Here is how I understand that it works:

HestiaCP uses templates to generate the actual config files for both nginx and apache2

The generated config files are placed in the home directory 
of the User/domain like this:
/home/dave/conf/web/gldn.page/nginx.conf
/home/dave/conf/web/gldn.page/nginx.ssl.conf
and 
/home/dave/conf/web/gldn.page/apache2.conf
/home/dave/conf/web/gldn.page/apache2.ssl.conf

The nginx is a reverse proxy in front of the apache server

The NGINX server listens on port 443
and then proxies to port 8080 where apache picks the request up.

The config:
/home/dave/conf/web/gldn.page/nginx.ssl.conf


server {
    listen      78.110.163.102:443 ssl http2;
    server_name gldn.page *.gldn.page;
    ssl_certificate      /etc/letsencrypt/live/gldn.page/cert.pem;
    ssl_certificate_key  /etc/letsencrypt/live/gldn.page/privkey.pem;
    ssl_stapling on;
    ssl_stapling_verify on;
    error_log  /var/log/apache2/domains/gldn.page.error.log error;

    include /home/dave/conf/web/gldn.page/nginx.hsts.conf*;

    location / {
        proxy_pass      https://78.110.163.102:8080;
        location ~* ^.+\.(jpg|gif|bmp|ico|svg|tif|tiff|css|js|htm|html|ttf|otf|webp|woff|txt|csv|rtf|doc|docx|xls|xlsx|ppt|pptx|odf|odp|ods|odt|pdf|psd|ai|eot|eps|ps|zip|tar|tgz|gz|rar|bz2|7z|aac|m4a|mp3|mp4|ogg|wav|wma|3gp|avi|flv|m4v|mkv|mov|mpeg|mpg|wmv|exe|iso|dmg|swf)$ {
            root           /home/dave/web/gldn.page/public_html;
            access_log     /var/log/apache2/domains/gldn.page.log combined;
            access_log     /var/log/apache2/domains/gldn.page.bytes bytes;
            expires        max;
            try_files      $uri @fallback;
        }
    }

    location /error/ {
        alias   /home/dave/web/gldn.page/document_errors/;
    }

    location @fallback {
        proxy_pass      https://78.110.163.102:8443;
    }

    location ~ /\.(?!well-known\/|file) {
       deny all;
       return 404;
    }

It's main use appears to be the caching of static objects,
the fallback uri is port 8443 which apache listens for.

As I understand it, the request from an internet client is decrypted
by the LE certs and sent Apache2 server on port 8080

The NGINX server also listens on port 80 and does a 301 redirect to HTTPS

/home/dave/conf/web/gldn.page/nginx.conf

server {
    listen      78.110.163.102:80;
    server_name gldn.page *.gldn.page;

    include /home/dave/conf/web/gldn.page/nginx.forcessl.conf*;
       **this does a 301 redirect to HTTPS**

    location / {
        proxy_pass      http://78.110.163.102:8080;
        location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|tif|tiff|css|js|htm|html|ttf|otf|webp|woff|txt|csv|rtf|doc|docx|xls|xlsx|ppt|pptx|odf|odp|ods|odt|pdf|psd|ai|eot|eps|ps|zip|tar|tgz|gz|rar|bz2|7z|aac|m4a|mp3|mp4|ogg|wav|wma|3gp|avi|flv|m4v|mkv|mov|mpeg|mpg|wmv|exe|iso|dmg|swf)$ {
            root           /home/dave/web/gldn.page/public_html;
            access_log     /var/log/apache2/domains/gldn.page.log combined;
            access_log     /var/log/apache2/domains/gldn.page.bytes bytes;
            expires        max;
            try_files      $uri @fallback;
        }
    }

    location /error/ {
        alias   /home/dave/web/gldn.page/document_errors/;
    }

I would think that after the 301 redirect there would be no
proxy to 8080 or any caching happening.

NOW the Apache2 webserver
This listens on port 8080

/home/dave/conf/web/gldn.page/apache2.conf

<VirtualHost 78.110.163.102:8080>

    ServerName gldn.page
    ServerAlias *.gldn.page
    ServerAdmin info@gldn.page
    DocumentRoot /home/dave/web/gldn.page/public_html
    ScriptAlias /cgi-bin/ /home/dave/web/gldn.page/cgi-bin/
    Alias /vstats/ /home/dave/web/gldn.page/stats/
    Alias /error/ /home/dave/web/gldn.page/document_errors/
    #SuexecUserGroup dave dave
    CustomLog /var/log/apache2/domains/gldn.page.bytes bytes
    CustomLog /var/log/apache2/domains/gldn.page.log combined
    ErrorLog /var/log/apache2/domains/gldn.page.error.log

    IncludeOptional /home/dave/conf/web/gldn.page/apache2.forcessl.conf*

    <Directory /home/dave/web/gldn.page/stats>
        AllowOverride All
    </Directory>
    <Directory /home/dave/web/gldn.page/public_html>
        AllowOverride All
        Options +Includes -Indexes +ExecCGI
    </Directory>

    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php/php8.0-fpm-gldn.page.sock|fcgi://localhost"
    </FilesMatch>
    SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0

    IncludeOptional /home/dave/conf/web/gldn.page/apache2.conf_*
    IncludeOptional /etc/apache2/conf.d/*.inc
</VirtualHost>

Note:
There are no files:
/home/dave/conf/web/gldn.page/apache2.forcessl.conf*
/home/dave/conf/web/gldn.page/apache2.conf_*

Only /etc/apache2/conf.d/phpmyadmin.inc

What does this do ?
SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0

Hopefully it prevents someone from just going directly to port 8080
and circumventing the proxy server and https !!

FINALLY we have the
/home/dave/conf/web/gldn.page/apache2.ssl.conf

The one below is the default config - where you can see
the three cert files

<VirtualHost 78.110.163.102:8443>

    ServerName gldn.page
    ServerAlias *.gldn.page
    ServerAdmin info@gldn.page
    DocumentRoot /home/dave/web/gldn.page/public_html
    ScriptAlias /cgi-bin/ /home/dave/web/gldn.page/cgi-bin/
    Alias /vstats/ /home/dave/web/gldn.page/stats/
    Alias /error/ /home/dave/web/gldn.page/document_errors/
    #SuexecUserGroup dave dave
    CustomLog /var/log/apache2/domains/gldn.page.bytes bytes
    CustomLog /var/log/apache2/domains/gldn.page.log combined
    ErrorLog /var/log/apache2/domains/gldn.page.error.log
    <Directory /home/dave/web/gldn.page/stats>
        AllowOverride All
    </Directory>
    <Directory /home/dave/web/gldn.page/public_html>
        AllowOverride All
        SSLRequireSSL
        Options +Includes -Indexes +ExecCGI
        </Directory>
    SSLEngine on
    SSLVerifyClient none
    SSLCertificateFile /home/dave/conf/web/gldn.page/ssl/gldn.page.crt
    SSLCertificateKeyFile /home/dave/conf/web/gldn.page/ssl/gldn.page.key
    SSLCertificateChainFile /home/dave/conf/web/gldn.page/ssl/gldn.page.ca

    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php/php8.0-fpm-gldn.page.sock|fcgi://localhost"
    </FilesMatch>
    SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0

    IncludeOptional /home/dave/conf/web/gldn.page/apache2.ssl.conf_*
    IncludeOptional /etc/apache2/conf.d/*.inc
</VirtualHost>

I tried changing the certificate paths to:

SSLCertificateFile /etc/letsencrypt/live/gldn.page/cert.pem;
SSLCertificateKeyFile /etc/letsencrypt/live/gldn.page/privkey.pem;
SSLCertificateChainFile /etc/letsencrypt/live/gldn.page/chain.pem;

Would you expect this to be correct?

( I get an error - apache2 server will not restart )

The error is in the apache2 config:

apachectl configtest

AH00526: Syntax error on line 30 of /etc/apache2/conf.d/domains/gldn.page.ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/gldn.page/cert.pem;' does not exist or is empty
Action 'configtest' failed.

However:
:/etc/letsencrypt/live/gldn.page# ls -la

total 24
drwxr-xr-x 2 root root 4096 Jun  9 10:09 .
drwx------ 7 root root 4096 Jun  8 09:03 ..
lrwxrwxrwx 1 root root   33 Jun  7 20:15 cert.pem -> ../../archive/gldn.page/cert1.pem
lrwxrwxrwx 1 root root   34 Jun  7 20:15 chain.pem -> ../../archive/gldn.page/chain1.pem
lrwxrwxrwx 1 root root   38 Jun  7 20:15 fullchain.pem -> ../../archive/gldn.page/fullchain1.pem
-rw-r--r-- 1 root root 5595 Jun  9 10:09 gldn.page.crt
-rw------- 1 root root 1708 Jun  8 21:10 gldn.page.key
lrwxrwxrwx 1 root root   36 Jun  7 20:15 privkey.pem -> ../../archive/gldn.page/privkey1.pem
-rw-r--r-- 1 root root  692 Jun  7 20:15 README

root@expressresponse:/etc/letsencrypt/live/gldn.page#  cat cert.pem
-----BEGIN CERTIFICATE-----
MIIFJjCCBA6gAwIBAgISBLV5s/k7KmTYDsjJzS9xqRihMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMjA2MDcxODE1MzhaFw0yMjA5MDUxODE1MzdaMBQxEjAQBgNVBAMT
CWdsZG4ucGFnZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMp/Z+Iw
NM8kWdpWgLElfm6rREDdDbPUxb4Yh5v/WWnnJwNtrRjoU2XR/mCPG4ARFnW/6V37
EIGN2yJP24BORHoS3h3hFyg7fojslj2CmycrBxFezlz0Ias8t7dsc2s+s0im2sjl
jvtbk385m749o3dYA1LQHOd3Bca3QBNsNdEbZ1NenoRjc5Pd+Qeuns2vPoPZHZWn
aCLACmSPvCP42Bo2U0Qt723Bory3BffxQez4TEFrFyPGQYXSo+3qHFY4t11GaFFx
ad6h01q6CHI+Y44ervrNBLYRlSSYN8qLfJgKGTo0VR/UYDuG2C9IPTjE6qxj/FUL
2vaIRtPE7kd4nvkCAwEAAaOCAlIwggJOMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE
FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU
wuQog9Ah07QwHE0LKKWuJ+jNTUswHwYDVR0jBBgwFoAUFC6zF7dYVsuuUAlA5h+v
dHNlbmNyeXB0Lm9yZzCCAQUGCisGAQQB1nkCBAIEgfYEgfMA8QB3AN+lXqtogk8f
bK3uuF9OPlrqzaISpGpejjsSwCBEXCpzAAABgT+YDuUAAAQDAEgwRgIhAIWDh5g8
7vLe90yUxQxyyPfgDVeDSyVmcP2mgvglKNIOAiEArnNf9Yl8RW4DZMf2f9S566rV
sLJQ1wsm8o95M3DGGKcAdgBGpVXrdfqRIDC1oolp9PN9ESxBdL79SbiFq/L8cP5t
RwAAAYE/mA8IAAAEAwBHMEUCICSTTYk15OJhlSafBUcXqMU2GWjUofROKnzdX/E8
qOIqAiEAmpf3LG/xeEKjNyZ3xcN94VoAFlS/I1+eMnTaVTJHd/UwDQYJKoZIhvcN
AQELBQADggEBADHqSw8QPlFZgh5+DB7UJggUTQOgaoEVZsh7dyEfPuNrmTRR8MpA
+Wi3b0dxXw3oCiewqOASpHW+OxuqjlDz1ofjKQ/WEsOMxEHhM570B12xYxLdu701
AKes8yqSepJzspPxx3Q+ThdIYk2wVTkYOXhKBmhYdyKIA7uQPT/W8NgUA4BhQ8/X
lbdIXqMlgIXLBUpx1BY+AP1tbh4FoxEUezvUD/ChNwzaF1IjTGa7jb8WVaDY40uA
SfQ2Lqi0MxtDhTD5UJvlVaS3+/3UC7Aueo+czIFj7I8gWULS4yvoRyRs2+pFkXeH
URpzVsoJGL/VcEZz13eaQPPhJ87Yyw6haPk=
-----END CERTIFICATE-----

So , the cert.pem is present and looks like a certificate !!

If both nginx and Apache are on the same host and your host is secure, it's kinda useless to use HTTPS for the reverse proxy part between nginx and Apache. If Apache is not actually accessible from the web, just have Apache use HTTP and have nginx terminate the TLS and reverse proxy it to http://127.0.0.1:8080 ?

I find the setup overly complicated tho.. Not sure what the benefits are.

2 Likes

I completely agree - it has taken me a week to work out what is going on
and to understand it ( especially the templates)

I think that is roughly what I described it is doing.
Except that it is doing proxy to https://78.110.163.102:8080

So, should I change that to:

location / {
        proxy_pass      http://127.0.0.1:8080;

And then on the apache2
change to:

<VirtualHost 127.0.0.1:8080>

Would that be better ?

1 Like

With that situation you wouldn't need to configure a TLS certificate for Apache, which would make things a little bit more easy.

2 Likes

Yes, that would be much easier !

What about this fallback proxy pass in the
/home/dave/conf/web/gldn.page/nginx.ssl.conf ??

Is this necessary ??

I don't know.

2 Likes

You can't do both HTTP and HTTPS on the same port [not without major effort].
So... one of those is wrong.

3 Likes

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