[Ghost blogs] DNS records en SSL Let's Encrypt

[ironheart]

Hoi,

Ik heb een VPS bij TransIP (Debian) en daar draait één Ghost Blog op met een SSL certificaat van Let's Encrypt. Nu wil ik een tweede blog gaan toevoegen. De installatie ervan is gelukt maar ik heb ruzie met Let's Encrypt. Ik heb port 80 dichtstaan en alleen 443 open.

Blog 1 is bereikbaar via https://domeinnaam1.nl
Blog 2 is bereikbaar via https://domeinnaam2.nl

Echter, beiden zijn ze NIET bereikbaar via www. Dus:
Blog 1 is NIET bereikbaar via https://www.domeinnaam1.nl
Blog 2 is NIET bereikbaar via https://www.domeinnaam2.nl

Voor beide domeinnamen heb ik een CNAME record aangemaakt met WWW verwijzing naar @
en @ verwijst weer naar de VPS zelf.

Ik vermoed dat dit in de NGINX configuratie zit. Voor beide domeinnamen heb ik 2 conf files in sites-available.

domeinnaam1.nl-ssl.conf:

code:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name domeinnaam1.nl;
    root /var/www/domeinnaam1/system/nginx-root; # Used for acme.sh SSL verification (https://acme.sh)

    ssl_certificate /etc/letsencrypt/domeinnaam1.nl/fullchain.cer;
    ssl_certificate_key /etc/letsencrypt/domeinnaam1.nl/domeinnaam1.nl.key;
    include /etc/nginx/snippets/ssl-params.conf;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:2368;

    }

    location ~ /.well-known {
        allow all;
    }

    client_max_body_size 1g;
}

www.domeinnaam1.nl-ssl.conf

code:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name www.domeinnaam1.nl;
    root /var/www/domeinnaam1/system/nginx-root; # Used for acme.sh SSL verification (https://acme.sh)

    return 301 https://domeinnaam1.nl$request_uri;

#    ssl_certificate /etc/letsencrypt/www.domeinnaam1.nl/fullchain.cer;
#    ssl_certificate_key /etc/letsencrypt/www.domeinnaam1.nl/www.domeinnaam1.nl.key;
#    include /etc/nginx/snippets/ssl-params.conf;

#    location / {
#        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#        proxy_set_header X-Forwarded-Proto $scheme;
#        proxy_set_header X-Real-IP $remote_addr;
#        proxy_set_header Host $http_host;
#        proxy_pass http://127.0.0.1:2368;

#    }

    location ~ /.well-known {
        allow all;
    }

    client_max_body_size 1g;
}

Als ik nu navigeer naar https://domeinnaam1.nl dan gaat het goed echter als ik navigeer naar https://www.domeinnaam1.nl dan krijg ik dit:



Doe ik dit zo wel goed? Obvisouly niet want dan zou het werken, maar waar gaat het mis?

[rnark]

Als het goed is kan je wel zien welk certificaat geserveerd wordt, is dat het certificaat dat je verwacht? En heeft dit certificaat zowel domein.nl als www.domein.nl? En welke IP adressen krijg je terug wanneer je de domeinnamen pingt?

[ironheart]

Hoi Mark,

Als ik navigeer naar https://www.domeinnaam1.nl dan krijg ik die foutmelding in de pagina die je ziet in mijn vorige post. Echter, als ik nu op het slotje klik dan zie ik daar dit staan en op het rode stuk staat:
domeinnam2.nl

Dit lijkt dus niet goed te gaan..

Als het goed is kan je wel zien welk certificaat geserveerd wordt, is dat het certificaat dat je verwacht? En heeft dit certificaat zowel domein.nl als www.domein.nl? En welke IP adressen krijg je terug wanneer je de domeinnamen pingt?

Nee het is niet het certificaat wat ik verwacht inderdaad. Hij toont alleen domeinnaam1.nl dus zonder de www. Pingt beide ( of ja, alle 4 ) naar hetzelfde adres.

[ Voor 30% gewijzigd door ironheart op 31-07-2023 17:12 ]

[Hero of Time]

Als je alleen 'server_name <domein.nl>;' gebruikt, is het niet gek dat je opeens een certificaat van je andere domein geserveerd krijgt. Een van de twee wordt als default gebruikt wanneer er geen match is op domeinnaam in het verzoek. Blader maar eens voor de grap naar het IP adres van de server en kijk welk certificaat je aangeboden krijgt.

Zorg dus dat je fatsoenlijke aliassen toevoegt aan je site config in Nginx, zodat het ook de juiste site en config gebruikt. Zie ook de documentatie: https://nginx.org/en/docs/http/server_names.html.

[ironheart]

Hero of Time schreef op maandag 31 juli 2023 @ 20:00:
Als je alleen 'server_name <domein.nl>;' gebruikt, is het niet gek dat je opeens een certificaat van je andere domein geserveerd krijgt. Een van de twee wordt als default gebruikt wanneer er geen match is op domeinnaam in het verzoek. Blader maar eens voor de grap naar het IP adres van de server en kijk welk certificaat je aangeboden krijgt.

Zorg dus dat je fatsoenlijke aliassen toevoegt aan je site config in Nginx, zodat het ook de juiste site en config gebruikt. Zie ook de documentatie: https://nginx.org/en/docs/http/server_names.html.

Die volg ik niet helemaal. Ik heb namelijk 2 configs, zie mijn eerste post. Één voor zowel www.domeinnaam1.nl als zonder www dus alleen domeinnaam1.nl
Als ik de vps op IP adres benader dan krijg ik de pagina van domeinnaam2.nl te zien.

Ik heb je link bekeken en mijn config aangepast:

code:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name *.domeinnaam1.nl;
    root /var/www/domeinnaam1/system/nginx-root; # Used for acme.sh SSL verification (https://acme.sh)

    ssl_certificate /etc/letsencrypt/domeinnaam1.nl/fullchain.cer;
    ssl_certificate_key /etc/letsencrypt/domeinnaam1.nl/domeinnaam1.nl.key;
    include /etc/nginx/snippets/ssl-params.conf;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:2368;

    }

    location ~ /.well-known {
        allow all;
    }

    client_max_body_size 1g;
}

Als ik nu naar https://www.domeinnaam1.nl ga dan krijg ik nog steeds de SSL error maar wel met de juiste domein naam in het certificaat. Ik denk dus dat mijn certificaat alleen voor domeinnaam1.nl is niet voor www.domeinnaam1.nl én domeinnaam1.nl

Klopt dat? En hoe krijg ik dat opgelost? Idealiter door het toevoegen van één domein bij het certificaat, toch?

edit:
Oh en als ik nu naar https://domeinnaam1.nl ga krijg ik ook een ssl error.

edit2:
Aaaannddd we're back where we started.
Heb de SSLS nou goed staan maar opnieuw met www ervoor doen ze het niet.
Ik snap het niet. Heb de wildcard bij beide domeinnamen ingezet maar geen succes. Moet ik ook een certificaat genereren voor de domeinen mét www ervoor? Zo ja, hoe doe ik dat dan?

[ Voor 8% gewijzigd door ironheart op 31-07-2023 21:00 ]

[Hero of Time]

ironheart schreef op maandag 31 juli 2023 @ 20:36:
[...]


Die volg ik niet helemaal. Ik heb namelijk 2 configs, zie mijn eerste post. Één voor zowel www.domeinnaam1.nl als zonder www dus alleen domeinnaam1.nl

Als je tegen Nginx zegt dat een stukje config, een server {} blok, geldig is voor example.org en je hebt in DNS het IP adres van je server voor zowel example.org als www.example.org én voorbeeld.nl, dan gaat je server het eerste server {} blok serveren dat het heeft geladen in je config en dat is niet per definitie waar example.org is opgegeven als server_name. Immers, het weet niet dat het dat stuk moet serveren want je hebt die namen niet opgegeven.

Als ik de vps op IP adres benader dan krijg ik de pagina van domeinnaam2.nl te zien.

Ik heb je link bekeken en mijn config aangepast:

code:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name *.domeinnaam1.nl;
    root /var/www/domeinnaam1/system/nginx-root; # Used for acme.sh SSL verification (https://acme.sh)

    ssl_certificate /etc/letsencrypt/domeinnaam1.nl/fullchain.cer;
    ssl_certificate_key /etc/letsencrypt/domeinnaam1.nl/domeinnaam1.nl.key;
    include /etc/nginx/snippets/ssl-params.conf;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:2368;

    }

    location ~ /.well-known {
        allow all;
    }

    client_max_body_size 1g;
}

Als ik nu naar https://www.domeinnaam1.nl ga dan krijg ik nog steeds de SSL error maar wel met de juiste domein naam in het certificaat. Ik denk dus dat mijn certificaat alleen voor domeinnaam1.nl is niet voor www.domeinnaam1.nl én domeinnaam1.nl

Je config is nu iig beter. Mooier had geweest als je 'server_name domein1.nl www.domein1.nl;' had gebruikt, maar dit werkt ook.

edit:
Oh en als ik nu naar https://domeinnaam1.nl ga krijg ik ook een ssl error.

edit2:
Aaaannddd we're back where we started.
Heb de SSLS nou goed staan maar opnieuw met www ervoor doen ze het niet.
Ik snap het niet. Heb de wildcard bij beide domeinnamen ingezet maar geen succes. Moet ik ook een certificaat genereren voor de domeinen mét www ervoor? Zo ja, hoe doe ik dat dan?

Als je niet aangeeft bij Let's Encrypt/Certbot dat je een multi-domein of wildcard certificaat wilt én aangeeft voor welke domeinen, ga je logischerwijs een certificaat krijgen voor maar 1 domein.

Hoe heb je Certbot ingesteld dan? Want dat mist hier nog.

[ironheart]

Ik denk dat dat het is inderdaad. Nu heb ik in sites-available een extra config aangemaakt met www.domeinnaam1.nl en daarvoor wil ik nu ook het certficaat gaan genereren:

code:

root@domeinnaam1:/etc/letsencrypt# ./acme.sh --issue --home /etc/letsencrypt --domain www.domeinnaam1.nl --log --webroot /var/www/domeinnaam1/system/nginx-root --reloadcmd "nginx -s reload" --accountemail [e-mail]

Maar de response is helaas:

[Tue 01 Aug 2023 10:09:39 AM CEST] www.domeinnaam1.nl:Verify error:"error":{
[Tue 01 Aug 2023 10:09:39 AM CEST] Please check log file for more details: /etc/letsencrypt/acme.sh.log[/quote]
[quote]

En de log zegt:

code:

[Tue 01 Aug 2023 10:09:34 AM CEST] _post_url='https://acme.zerossl.com/v2/DV90/authz/K6yeLkfFZ4Gsd6VnVhw62Q'
[Tue 01 Aug 2023 10:09:34 AM CEST] _CURL='curl --silent --dump-header /etc/letsencrypt/http.header  -L  -g '
[Tue 01 Aug 2023 10:09:35 AM CEST] _ret='0'
[Tue 01 Aug 2023 10:09:35 AM CEST] code='200'
[Tue 01 Aug 2023 10:09:35 AM CEST] Pending, The CA is processing your order, please just wait. (4/30)
[Tue 01 Aug 2023 10:09:35 AM CEST] sleep 2 secs to verify again
[Tue 01 Aug 2023 10:09:38 AM CEST] checking
[Tue 01 Aug 2023 10:09:38 AM CEST] =======Begin Send Signed Request=======
[Tue 01 Aug 2023 10:09:38 AM CEST] url='https://acme.zerossl.com/v2/DV90/authz/K6yeLkfFZ4Gsd6VnVhw62Q'
[Tue 01 Aug 2023 10:09:38 AM CEST] payload
[Tue 01 Aug 2023 10:09:38 AM CEST] POST
[Tue 01 Aug 2023 10:09:38 AM CEST] _post_url='https://acme.zerossl.com/v2/DV90/authz/K6yeLkfFZ4Gsd6VnVhw62Q'
[Tue 01 Aug 2023 10:09:38 AM CEST] _CURL='curl --silent --dump-header /etc/letsencrypt/http.header  -L  -g '
[Tue 01 Aug 2023 10:09:39 AM CEST] _ret='0'
[Tue 01 Aug 2023 10:09:39 AM CEST] code='200'
[Tue 01 Aug 2023 10:09:39 AM CEST] www.domeinnaam1.nl:Verify error:"error":{
[Tue 01 Aug 2023 10:09:39 AM CEST] pid
[Tue 01 Aug 2023 10:09:39 AM CEST] No need to restore nginx, skip.
[Tue 01 Aug 2023 10:09:39 AM CEST] _clearupdns
[Tue 01 Aug 2023 10:09:39 AM CEST] dns_entries
[Tue 01 Aug 2023 10:09:39 AM CEST] skip dns.
[Tue 01 Aug 2023 10:09:39 AM CEST] _on_issue_err
[Tue 01 Aug 2023 10:09:39 AM CEST] Please check log file for more details: /etc/letsencrypt/acme.sh.log
[Tue 01 Aug 2023 10:09:39 AM CEST] =======Begin Send Signed Request=======
[Tue 01 Aug 2023 10:09:39 AM CEST] url='https://acme.zerossl.com/v2/DV90/chall/1KWqDvoJObk-22kXXzp8gw'
[Tue 01 Aug 2023 10:09:39 AM CEST] payload='{}'
[Tue 01 Aug 2023 10:09:39 AM CEST] POST
[Tue 01 Aug 2023 10:09:39 AM CEST] _post_url='https://acme.zerossl.com/v2/DV90/chall/1KWqDvoJObk-22kXXzp8gw'
[Tue 01 Aug 2023 10:09:39 AM CEST] _CURL='curl --silent --dump-header /etc/letsencrypt/http.header  -L  -g '
[Tue 01 Aug 2023 10:09:39 AM CEST] _ret='0'
[Tue 01 Aug 2023 10:09:39 AM CEST] code='200'

[Hero of Time]

Maar je vraagt alsnog geen wildcard/multi-domain certificaat aan. Hoe ben je aan dat ./acme.sh commando gekomen? Debian heeft gewoon certbot in de repo staan: https://packages.debian.org/bookworm/certbot.

Ik ken overigens 2 manieren waarop Let's Encrypt de verificatie uitvoert en dat is voor een nieuw certificaat over poort 80 waarna het voor verlengingen over 443/https gaat, en via een DNS record.

In je log staat er 'skip dns'. Het doet de tweede optie niet, het zal dan terugvallen op m'n eerste optie. En je doet met nginx geen poort 80 serveren. Dus tenzij Acme zelf als webserver gaat fungeren op poort 80, zal het falen.

Oh, en nu herinner ik mij wel op tijd: dit topic hoort in Server Software en verplaats het dan ook daarheen. LNX -> SSC.

[ironheart]

I did it, ik gebruikte de SSL configurator van Ghost Blog zelf maar heb nu de certbot gebruikt op basis van jouw aanraden. Nu werkt het, thanks! Final question: Ik heb poort 80 weer dichtgezet omdat ik 443 alleen serveer. Denk je dat dat slim is of zou je toch aan raden om de pagina ook nog via poort 80 aan te blijven bieden?

[Hero of Time]

Men gebruikt poort 80 tegenwoordig voornamelijk omdat als je een adres invult, je browser nog steeds standaard over plain http gaat en niet eerst https probeert. Waarna het dus doodleuk zegt "kan site niet bereiken". Wat er effectief wordt toegepast nu, is domweg een redirect van http naar https. Genoeg info online te vinden hoe dit te doen is. Maakt weinig uit of je het in hetzelfde server {} config blok zet, of een aparte, al zou een aparte wel beide domeinen tegelijk kunnen doen, want je redirect dat wat gevraagd wordt naar https.

[deHakkelaar]

Ter info, over het algemeen heb je drie soorten SSL/TLS certificaten:

1. Een cert geldig voor alleen een enkel domein zoals bv: domeinnaam.nl.
2. Een wildcard cert bv: *.domeinnaam.nl
3. En een SAN cert (Subject Alternative Name) welke allemaal aliassen kan bevatten zoals bv www.domeinnaam.nl, mail.domeinnaam.nl, anderdomein.nl etc.

Die laatste heeft voorkeur als je een enkele cert wilt genereren die voor meerdere domeinen gebruikt kan worden.
Een wildcard cert is namelijk te open en kan als een beveiligingsrisico worden beschouwd.

Onder is een voorbeeld van zo'n (EDIT: foute) wildcard cert gecombineerd met SAN:

$ echo | openssl s_client -connect tweakers.net:443 -servername tweakers.net </dev/null 2>/dev/null | openssl x509 -noout -text
[..]
        Subject: CN = *.tweakers.net
[..]
            X509v3 Subject Alternative Name:
                DNS:*.hardware.info, DNS:*.tweakblogs.net, DNS:*.tweakers.be, DNS:*.tweakers.mobi, DNS:*.tweakers.net, DNS:*.tweakers.nl, DNS:*.tweakers.tv, DNS:*.tweakimg.net, DNS:*.tweakzones.net, DNS:hardware.info, DNS:tweakblogs.net, DNS:tweakers.be, DNS:tweakers.mobi, DNS:tweakers.net, DNS:tweakers.nl, DNS:tweakers.tv, DNS:tweakimg.net, DNS:tweakzones.net

EDIT: Ow dit is veiliger zonder wildcards ter vergelijk:

$ echo | openssl s_client -connect nos.nl:443 -servername www.nos.nl </dev/null 2>/dev/null | openssl x509 -noout -text | grep 'Subject:.* CN =\|Alternative Name\|DNS:'
        Subject: CN = nos.nl
            X509v3 Subject Alternative Name:
                DNS:nos.nl, DNS:www.nos.nl, DNS:cf.nos.nl

SAN aliassen kun je opgeven met:

$ man certbot
[..]
            -d DOMAIN, --domains DOMAIN, --domain DOMAIN
                                  Domain names to apply. For multiple domains you can
                                  use multiple -d flags or enter a comma separated list
                                  of domains as a parameter. The first domain provided
                                  will be the subject CN of the certificate, and all
                                  domains will be Subject Alternative Names on the
                                  certificate. The first domain will also be used in
                                  some software user interfaces and as the file paths
                                  for the certificate and related material unless
                                  otherwise specified or you already have a certificate
                                  with the same name. In the case of a name collision it
                                  will append a number like 0001 to the file path name.
                                  (default: Ask)

[ Voor 20% gewijzigd door deHakkelaar op 02-08-2023 09:16 . Reden: typo ]

[ironheart]

Hoi,

Alles lijkt nu perfect te werken gelukkig. Dank voor jullie hulp. Er is alleen één ding wat niet werkt nu, geen ramp maar kan niet vinden waar dit in zou moeten zitten.
Alleen als ik op de LINK View Site klik krijg ik een page not found.

[Hero of Time]

Dat is makkelijk te achterhalen: F12, tabje Network en de webserver logs. Zie je wat er aangeroepen wordt en waar de 404 vandaan komt.