./well-known wordt niet gevonden vanwege RewriteRule

[AW_Bos]

Mijn vraag

Ik heb een klein poosje geleden mijn site geüpdated, en echter krijg ik opeens berichten dat de ./well-known directory op de server (voor Let's Encrypt) niet zichtbaar is. Ik ben erachter gekomen dat het door mijn .htaccess komt, waarmee ik alles, (maar behalve bestanden en directories!) naar de index.php doorstuur voor deftige URL's. Deze geeft dus in mijn webapplicatie dus een eigen custom 404.

De .htaccess is als volgt:

code:

Options +FollowSymLinks
Options -Indexes

AcceptPathInfo On
RewriteEngine On

### Strip fbclid crap
RewriteCond %{QUERY_STRING} "fbclid=" [NC]
RewriteRule (.*) /$1? [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA]

ErrorDocument 401 /http_status_code?error=401
ErrorDocument 403 /http_status_code?error=403
ErrorDocument 404 /http_status_code?error=404
ErrorDocument 500 /http_status_code?error=500

Relevante software en hardware die ik gebruik
- Directadmin, Apache

Wat ik al gevonden of geprobeerd heb

Ik ben er al achtergekomen dat het aan mijn .htaccess ligt die de directory-alias /.well-known
(staat in de algemene webroot en dus voor alle domeinen @ server) niet laat zien. Als ik deze even aan de kant zet, dan werkt het wel.

Ik heb dit al geprobeerd, maar zonder resultaat:

code:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^\.well-known/.+ - [END]

Ook heb ik dit uitgetest, maar zonder resultaat:

code:

RewriteCond %{REQUEST_FILENAME} !-F

En dit als eerste conditie, werkt ook al niet

code:

# If the URL starts "/.well-known/" then stop here.
RewriteRule ^\.well_known/. - [L]

Wat is er mis in mijn .htaccess om de algemene map /.well-known te negeren?

[ Voor 5% gewijzigd door AW_Bos op 14-04-2020 12:46 ]

[Vloris]

Ik weet niet precies wat er mis gaat, maar voor RewriteCond/RewriteRule regels maakt de volgorde nogal uit in je .htaccess-bestand. Je zegt dat je een paar dingen daarmee geprobeerd hebt, maar waar heb je die toegevoegd? Onderaan? Dan snap ik dat het niet werkt, dan is de index.php rule allang uitgevoerd namelijk

[AW_Bos]

Bovenaan heb ik die uitgeprobeerd, maar ik merk dat een test.txt bestand in de algemene ./well-known wel gewoon te vinden is. Ik zat puur te wachten op een 403 op die directory, maar een ./well-known/text.txt werkt wel gewoon.

Dus feitelijk lijkt er niks aan de hand in mijn .htaccess.
BLijft alleen de vraag waarom ik op sommige domeinen een
SSL_ERROR_NO_CYPHER_OVERLAP krijg. Maar dat vogel ik even uit.

[xares]

Vloris schreef op dinsdag 14 april 2020 @ 13:33:
Ik weet niet precies wat er mis gaat, maar voor RewriteCond/RewriteRule regels maakt de volgorde nogal uit in je .htaccess-bestand. Je zegt dat je een paar dingen daarmee geprobeerd hebt, maar waar heb je die toegevoegd? Onderaan? Dan snap ik dat het niet werkt, dan is de index.php rule allang uitgevoerd namelijk

Als je DirectAdmin gebruikt zou in het volgende bestand /etc/httpd/conf/extra/httpd-alias.conf dit moeten staan:

Alias /.well-known "/var/www/html/.well-known/"

(en wat andere lines)

Zo niet moet je Let's encrypt even builden:

/usr/local/directadmin/custombuild
./build letsencrypt
./build rewrite_confs

[AW_Bos]

En dat staat er gewoon. En blijkbaar is de /.well-known prima te lezen met een test.txt bestand, op alle domeinen.

Maar het blijft vreemd dat ik een SSL_ERROR_NO_CYPHER_OVERLAP in mijn error log zie op www.subdomein.domein.tld en dat subdomein.domein.tld wel weer werkt.

Ook kreeg ik van Lets Encrypt al een mailtje dat het tijd is om wat certificaten te verlengen, wat blijkbaar niet gebeurt.

[Droefsnoet]

www.subdomein.domein.tld en subdomein.domein.tld zijn ook twee verschillende domeinen. Aangezien www. van zichzelf al een subdomein is, is www.subdomein.domein.tld dus eigenlijk subdomein.subdomein.domein.tld en moet die een ander certificaat hebben dan subdomein.domein.tld

[biomass]

Mogen we aannemen dat je geen TXT entries aan je DNS record kan/mag toevoegen? Dan ben je van de verplichte bestanden af..

[AW_Bos]

Droefsnoet schreef op dinsdag 14 april 2020 @ 13:46:
www.subdomein.domein.tld en subdomein.domein.tld zijn ook twee verschillende domeinen. Aangezien www. van zichzelf al een subdomein is, is www.subdomein.domein.tld dus eigenlijk subdomein.subdomein.domein.tld en moet die een ander certificaat hebben dan subdomein.domein.tld

Dat snap ik.
Het is tijden goed gegaan, totdat ik van de week deze error kreeg:

Error: http://www.beta.domain.tl...ge/letsencrypt_1586826706 is not reachable. Aborting the script.
dig output for www.beta.domain.tld:

En later een mail van Let's Encrypt dat de certs voor alles op die domain.tld vervalt over enkele weken.
Dus blijkbaar wordt voor één domein om een vage reden dus niet steeds verlengd Ik ben wel pas over gegaan naar CloudFlare, maar dat lijkt me nu niet meer relevant.

[ Voor 4% gewijzigd door AW_Bos op 14-04-2020 13:50 ]

[AW_Bos]

biomass schreef op dinsdag 14 april 2020 @ 13:48:
Mogen we aannemen dat je geen TXT entries aan je DNS record kan/mag toevoegen? Dan ben je van de verplichte bestanden af..

Geen idee hoe dat met DirectAdmin gaat...
Die maakt gewoon textbestanden in /.well-known

[ Voor 8% gewijzigd door AW_Bos op 14-04-2020 13:55 ]

[biomass]

Zo te zien kan het in principe wel: https://help.directadmin.com/item.php?id=552

[AW_Bos]

Maar waarom werkt het nu dan opeens niet meer?

- .htaccess is dus niks mis mee
- /.well-known is gewoon oproepbaar
En waarom de melding: SSL_ERROR_NO_CYPHER_OVERLAP op www.subdomein.domein.tld, plus dat de rest niet automagisch verlengd wordt.

[ Voor 37% gewijzigd door AW_Bos op 14-04-2020 13:58 ]

[Christoxz]

Ik heb ooit is een vergelijkbaar issue gehad waarbij SSL force uitzetten heeft geholpen, later deze weer aangezet en geen problemen meer gehad.

'SSL_ERROR_NO_CYPHER_OVERLAP' => An error occurred during a connection to (IP address name). Cannot communicate securely with peer: no common encryption algorithm(s).

[AW_Bos]

Die heb ik uitgezet. Nog steeds zie ik die melding. Maar misschien moet ik Apache nog even een schop geven of dat er ongeldig certificaat in de browser blijft hangen. Ook heb ik Lets Encrypt even opnieuw gebuilt met een nieuwe versie. Kijken wat het oplevert.

Anders ga ik morgen Cloudflare even eruit kicken, en kijken wat de certificaten dan zeggen als ik ze handmatig vernieuw. Dat kijkt wat makkelijker dan de overrulende CF-certificaten.

Wordt vervolgd....

[ Voor 70% gewijzigd door AW_Bos op 14-04-2020 14:26 ]

[Postman]

biomass schreef op dinsdag 14 april 2020 @ 13:48:
Mogen we aannemen dat je geen TXT entries aan je DNS record kan/mag toevoegen? Dan ben je van de verplichte bestanden af..

DNS is helaas niet zaligmakend. Als je geen DNS api ondersteuning hebt dan kun je handmatig elke 80 dagen je certificaat gaan vernieuwen.

[biomass]

Postman schreef op woensdag 15 april 2020 @ 00:37:
[...]

DNS is helaas niet zaligmakend. Als je geen DNS api ondersteuning hebt dan kun je handmatig elke 80 dagen je certificaat gaan vernieuwen.

Je hebt gelijk, ik had nog even niet door dat daar ook challenge response word toegepast. Dan heb je inderdaad een DNS api nodig. Afgelopen weekend heb ik m'n eerste twee Let's Encrypt certificaten ingeregeld en inregelen met TXT records leek me in eerste instantie eenvoudiger dan poort 80 en 443 openlaten...

@AW_Bos Ik ben vaak op deze site geweest om mijn eigen sites te controleren,
https://check-your-website.server-daten.de/?q=jouwsite.nl
Duurt enige minuten voor dat je resultaat ziet, maar is erg handig.

Volgens mij hoef je je niet druk te maken over www.subdomein.domein.tld vs subdomein.domein.tld,

er wordt gewoon gekeken of er een www subdomain bestaat voor het domein wat je aanvraagt.
Dat is niet noodzakelijk, alleen als je www.domein.tld in je Subject Alternative Name wilt toevoegen aan domein.tld (SAN = domein.tld;www.domein.tld)

[AW_Bos]

@biomass Maar ik krijg wel een e-mail van letsencrypt, dat alle certificaten op dat domein binnenkort vervallen. Ik denk zelf dat het geen probleem is, nu ik cloudflare gebruik.

Ik heb een vermoeden dat die API voor het verlengen van de let's encrypt certificaten, een aanroep doet op het ip-adres van de server, i.p.v de hostname. En bij CF kom je dus op een centrale placeholder uit.

Maar het verklaart nog niet waarom www.subdomein.domein.tld een NO_CIPHER_OVERLAP error geeft en subdomein.domein.tld weer niet .
Maar goed, eigenlijk zijn subdomeinen met www ervoor best duf

[ Voor 7% gewijzigd door AW_Bos op 15-04-2020 11:07 ]

[biomass]

Is dat niet gewoon een bug dan, NO_CIPHER_OVERLAP voor een server die geen antwoord geeft is niet zo heel gek; de vragende server ziet 0 cipher protocols om mee te communiceren?
Als het over het domein gaat wat je werkend wilt krijgen, betekent het dat je niet dezelfde cipher schemas ondersteund op TLS 1.x als de server die de controle uitvoert.

[AW_Bos]

biomass schreef op woensdag 15 april 2020 @ 11:38:
Is dat niet gewoon een bug dan, NO_CIPHER_OVERLAP voor een server die geen antwoord geeft is niet zo heel gek; de vragende server ziet 0 cipher protocols om mee te communiceren?
Als het over het domein gaat wat je werkend wilt krijgen, betekent het dat je niet dezelfde cipher schemas ondersteund op TLS 1.x als de server die de controle uitvoert.

Zou misschien best eens kunnen. Ik ga het eens na.

[DJMaze]

xares schreef op dinsdag 14 april 2020 @ 13:36:
Als je DirectAdmin gebruikt zou in het volgende bestand /etc/httpd/conf/extra/httpd-alias.conf dit moeten staan:

Alias /.well-known "/var/www/html/.well-known/"

Dat lijkt mij een bug in DirectAdmin dan.

Ben zelf begonnen een control panel te ontwikkelen en gebruik

code:

Alias "/.well-known/acme-challenge/" "/var/www/html/.well-known/acme-challenge/"
<Directory "/var/www/html/.well-known/acme-challenge/">
    Require all granted
    Options -Indexes -FollowSymLinks
    AllowOverride None
</Directory>

Want de /.well-known/ map zou je zelf moeten beheren om meerdere redenen, zoals:
/.well-known/dnt-policy.txt
/.well-known/apple-app-site-association
/.well-known/autoconfig/mail

cPanel gebruikt /home/*/public_html/.well-known/ en dan heb je dus .htaccess problemen (al zijn die van @AW_Bos redelijk goed, niet perfect).


DirectAdmin/cPanel gaan er van uit dat er altijd www.*, mail.*, etc. zijn en dat die in je DNS staan.
En dat geeft natuurlijk ook problemen bij validatie (mijn cPanel logs stonden vol op de subdomeinen).

Vandaar dat ik met mijn eigen control panel bezig ben (en omdat de kosten voor cPanel bij mij 1000% omhoog vlogen).

[AW_Bos]

chriistiix schreef op dinsdag 14 april 2020 @ 14:02:
Ik heb ooit is een vergelijkbaar issue gehad waarbij SSL force uitzetten heeft geholpen, later deze weer aangezet en geen problemen meer gehad.

'SSL_ERROR_NO_CYPHER_OVERLAP' => An error occurred during a connection to (IP address name). Cannot communicate securely with peer: no common encryption algorithm(s).

Ik heb deze 'switch' uitgezet, en de boel is vannacht wel automatisch verlengd.

De SSL_ERROR_NO_CYPHER_OVERLAP blijft nog wel op www.subdomein.domein.tld, maar dat staat er dus los van .

[Paul]

HTTPS is meer dan alleen een certificaat, er komen (o.a.) ook ciphers en protocollen bij kijken. Als een client de ene set protocollen gebruikt en de server een andere set, zonder dat daar overlap in zit, dan kun je dus niet verbinden. Een oude browser op een oud OS kan tegenwoordig vaak niet meer verbinden met een moderne webserver vanwege dit probleem. Steeds meer sites zetten TLS 1.0 en TLS 1.1 uit, en bijvoorbeeld Internet Explorer op Windows XP kan dan niet meer verbinden met die server.

Mogelijk zit er ergens in issue in de config van je server dat sommige sites moeilijk doen. Ik zie dat je Apache gebruikt, en Certbot? Waar worden de virtualhosts gedefinieerd? Wordt www.subdomein.domein.tld daar ergens genoemd of gaat die naar de default site? Hebben alle virtualhosts hun eigen SSL configuratie of wordt dat overkoepelend geregeld?

Je kunt op https://www.ssllabs.com/ssltest/ testen wat er allemaal aan of uit staat en hoe veilig dat is

[ Voor 34% gewijzigd door Paul op 16-04-2020 09:03 ]