Www-loos-domein met "Fake LE"-certificaat

Alles over programmeren en development binnen de IT-wereld
Plaats reactie
Gebruikersavatar
meon
Administrator
Administrator
Berichten: 16729
Lid geworden op: 18 feb 2003, 22:02
Twitter: meon
Locatie: Bree
Uitgedeelde bedankjes: 574 keer
Bedankt: 770 keer

Hoi, ik werd vandaag geconfronteerd met een situatie die ik zelf niet verklaard krijg.

We hebben een domein via Combell geregistreerd, met hun "webforwarding"-functie om het domein zonder "www" te redirecten naar "met http://www.
Combell verklaart hier geen HTTPS op te ondersteunen, maar sinds vorige week (of zo?) lijkt dat wél het geval te zijn, maar krijg ik een untrusted certificaat voorgeschoteld:
Gcr5n0LV4x.png
Gcr5n0LV4x.png (5.26 KiB) 951 keer bekeken
Ik verwacht bij "niet ondersteund" gewoon een connection error, maar nu lijkt er wél een handshake te gebeuren en een certificaat uitgewisseld te worden. Combell support snapte mijn probleem niet (mijn issue was certificaat meldingen voor Outlook's Autodiscover-proces), maar ging het wel doorgeven aan hun productgroep.

Nu, wat ik niet snap is: hoe kan ik een certificaat krijgen met een of ander wazig Let's Encrypt-chain terwijl ik niet eens kan verbinden op poort 443?

Code: Selecteer alles

PS [08/11/2020 14:59:40] C:\> Test-NetConnection DOMAIN.com -Port 443                           
WARNING: TCP connect to (217.19.237.54 : 443) failed

ComputerName           : DOMAIN.com
RemoteAddress          : 217.19.237.54
RemotePort             : 443
InterfaceAlias         : INTERN
SourceAddress          : XX.XX.XX.XX
PingSucceeded          : True
PingReplyDetails (RTT) : 24 ms
TcpTestSucceeded       : False

PS [08/11/2020 15:02:22] C:\> Invoke-WebRequest https://DOMAIN.com                              
Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

PS [08/11/2020 15:02:34] C:\> add-type @"                                                              
>>     using System.Net;                                                                                                
>>     using System.Security.Cryptography.X509Certificates;                                                             
>>     public class TrustAllCertsPolicy : ICertificatePolicy {                                                          
>>         public bool CheckValidationResult(                                                                          
>>             ServicePoint srvPoint, X509Certificate certificate,                                                      
>>             WebRequest request, int certificateProblem) {                                                           
>>             return true;                                                                                             
>>         }                                                                                                            
>>     }                                                                                                                
>> "@                                                                                                                   

PS [08/11/2020 15:03:15] C:\> [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy                                                                                                             

PS [08/11/2020 15:03:16] C:\> Invoke-WebRequest https://DOMAIN.com                              
Invoke-WebRequest : The underlying connection was closed: The connection was closed unexpectedly.
Ik doe hier achtereenvolgens een connectietest op poort 443, een soort 'cURL' op HTTPS, ignore certificaatfouten en opnieuw een 'cURL' op HTTPS.
Modbreak:
Issue opgelost, effectief domein weggehaald.
Het domein in kwestie is "terumo-europe.com".
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5250
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 526 keer
Recent bedankt: 12 keer

je doet ten eerste al je connectietesten op DOMAIN.com terwijl je dus ingesteld hebt dat je in de browser redirect naar http://www.DOMAIN.com - en dat is een ander ip/server.
je zal dus je cert testen moeten doen op http://www.DOMAIN.com

edit:

ik krijg trouwens nergens op geen enkele manier een fake LE cert, dus lijkt me dat er ergens nog iets anders speelt bij je verbinding ook?
als ik

IPs die ik krijg:
dig +short A DOMAIN.com
217.19.237.54
dig +short A http://www.DOMAIN.com
DOMAIN.northeurope.cloudapp.azure.com.
40.113.66.14


http://DOMAIN.com => redirect naar https://www.DOMAIN.com/en-EMEA met geldig cert
http://www.DOMAIN.com/ => redirect naar https://www.DOMAIN.com/en-EMEA met geldig cert
https://DOMAIN.com => wil niet connecten (vermoedelijk dus geen redirect en is dat wat combell bedoelde dat ze het niet ondersteunen?)
DaNi0
Premium Member
Premium Member
Berichten: 744
Lid geworden op: 21 jun 2005, 13:45
Locatie: Oostende
Uitgedeelde bedankjes: 429 keer
Bedankt: 28 keer

Ter info, Fake LE zijn ongeldige testcertificaten om je Let's Encrypt setup te testen: https://letsencrypt.org/docs/staging-environment/
We highly recommend testing against our staging environment before using our production environment. This will allow you to get things right before issuing trusted certificates and reduce the chance of your running up against rate limits.
The staging environment intermediate certificate (“Fake LE Intermediate X1”) is issued by a root certificate not present in browser/client trust stores.
Laatst gewijzigd door DaNi0 11 aug 2020, 20:36, in totaal 1 gewijzigd.
CCatalyst
Elite Poster
Elite Poster
Berichten: 8271
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 526 keer
Recent bedankt: 12 keer

Splitter schreef: https://DOMAIN.com => wil niet connecten (vermoedelijk dus geen redirect en is dat wat combell bedoelde dat ze het niet ondersteunen?)
Jawel hoor, dan krijg je de situatie die OP beschrijft, zie screenshot beneden.

Voor het overige snap ik het probleem met het cert niet zozeer, poort 443 staat open en er wordt een certificaat van een CA voorgeschoteld dat de browser niet vertrouwt. Meer is er niet aan. Dat er los van het certificaat geen redirect gebeurt is een ander, tweede probleem dat niets met het certificaat te maken heeft.

@OP. Eenmaal je de site whitelist om voorbij het trust-probleem met het certificaat te raken reset de webserver de connectie na de TLS-negotiation, dus een redirect vindt momenteel niet plaats. Dit verklaart je cURL resultaat. Poort 443 staat gewoon open, maar de eerste failure is omwille van de trust-issue, en de tweede failure (als je trust negeert) is gewoon omdat de server de connectie om een of andere configuratiereden reset nadat TLS-negotiation gebeurd is.

Een TLS-redirect opzetten is vrij eenvoudig, doch je zal nood hebben aan een trusted cert voor de naam zonder www.

Afbeelding
yaris
Premium Member
Premium Member
Berichten: 564
Lid geworden op: 14 mei 2004, 00:16
Uitgedeelde bedankjes: 16 keer
Bedankt: 34 keer
Recent bedankt: 1 keer

Als ik me niet vergis, toen ik vroeger ook is een cert aanvroeg dan kreeg ik automagisch een cert met en zonder www. . Bij TS is dat niet het geval dan ... dat is wel kut.
Laatst gewijzigd door meon 12 aug 2020, 12:13, in totaal 1 gewijzigd.
Reden: Fullquote verwijderd
CCatalyst
Elite Poster
Elite Poster
Berichten: 8271
Lid geworden op: 20 jun 2016, 18:36
Uitgedeelde bedankjes: 19 keer
Bedankt: 526 keer
Recent bedankt: 12 keer

yaris schreef: Als ik me niet vergis, toen ik vroeger ook is een cert aanvroeg dan kreeg ik automagisch een cert met en zonder www. . Bij TS is dat niet het geval dan ... dat is wel kut.
Cert in kwestie heeft geen www SAN maar gezien het Let's Encrypt is maak je gemakkelijk en gratis een nieuwe die dat wel heeft.

Dat van die automatisch non-www erbij is iets dat je doorgaans automatisch van de betalende aanbieders krijgt opdat je geen twee certs zou moeten kopen.

Nu we toch over betalende certs bezig zijn, reminder dat deze maand de laatste kans is om nog een cert met een geldigheidsduur van 2 jaar te kopen. Certs uitgegeven vanaf 1 september mogen nog maximaal 1 jaar geldig zijn om door de browsers aanvaard te worden.
whof
Starter
Starter
Berichten: 1
Lid geworden op: 12 aug 2020, 00:43

Hoi Meon,

Kan je mij even je klantnummer doorgeven aub? Dan kunnen we je contacteren en wat uitleg geven bij wat er net misloopt en samen met jou een oplossing uitrollen.

Grts.
(Combell medewerker)
Gebruikersavatar
meon
Administrator
Administrator
Berichten: 16729
Lid geworden op: 18 feb 2003, 22:02
Twitter: meon
Locatie: Bree
Uitgedeelde bedankjes: 574 keer
Bedankt: 770 keer

CCatalyst schreef:Voor het overige snap ik het probleem met het cert niet zozeer, poort 443 staat open en er wordt een certificaat van een CA voorgeschoteld dat de browser niet vertrouwt.
Maar dat is net het probleem :-)

Poort 443 moet niet open staan en al helemaal geen untrusted certificaat voorschotelen.
Alle Outlook clients krijgen bij het opstarten namelijk nu deze popup omdat autodiscover de URL https://DOMAIN.com/autodiscover/autodiscover.xml uitprobeert.
20200812_050022.png
Tot vorige week reageerde de webserver bij Combell die de redirect verzorgt niet en werd bij autodiscover gewoon die test geskipped.

Mijn gok is dat iemand daar een test naar productie gepushed heeft om ook https mogelijk te maken bij hun redirect-service, gebruik makend van Let’s Encrypt-certificaten, zoals dat momenteel ook reeds bij bNamed nu mogelijk is.

We gaan nu een workaround pushen door de setting ”ExcludeHttpsRootDomain" in te stellen welke deze check in het autodiscover-proces zal bypassen.

Wat mij vooral voor een raadsel zette is het willekeurig (?) gedrag tussen m’n tests. Waarom zie wel een certificaat-issue, maar kan ik geen tcp-connect doen? Tenzij dat Powershell’s Test-Netconnection ook tegen dat certificaat botst en ik beter een klassieke telnet op poort 443 geprobeerd had..

@whof: ik heb hiervoor een ticket laten aanmaken bij jullie support-desk.
Gebruikersavatar
meon
Administrator
Administrator
Berichten: 16729
Lid geworden op: 18 feb 2003, 22:02
Twitter: meon
Locatie: Bree
Uitgedeelde bedankjes: 574 keer
Bedankt: 770 keer

meon schreef:Mijn gok is dat iemand daar een test naar productie gepushed heeft om ook https mogelijk te maken bij hun redirect-service, gebruik makend van Let’s Encrypt-certificaten, zoals dat momenteel ook reeds bij bNamed nu mogelijk is.
Net telefoontje van Combell gehad om mijn bovenstaande vermoeden te bevestigen :-)

Met andere woorden, het is een feature die binnenkort zal worden uitgerold en aangekondigd worden via nieuwsbrief, maar nu te vroeg in onafgewerkte staat actief was gezet.
Gebruikersavatar
Sasuke
userbase crew
userbase crew
Berichten: 5526
Lid geworden op: 13 aug 2003, 20:25
Locatie: Vlaanderen
Uitgedeelde bedankjes: 238 keer
Bedankt: 467 keer
Recent bedankt: 6 keer

Kon bijna niet anders hé ...

Daarnaast, ik zou zeker ook de "ExcludeHTTPredirect" en "ExcludeExplicitO365Endpoint"' opties zetten. Vooral die laatste is eigenlijk echt ne 'vieze' ...
Volgens MS om "DNS issues te verhelpen bij klanten" ... maar voor partners die bvb BitTitan gebruiken of in een Hybrid scenario zitten een merde :)
Who the fxxk is General Failure and why is he reading my hard disk ?
Afbeelding
Gebruikersavatar
meon
Administrator
Administrator
Berichten: 16729
Lid geworden op: 18 feb 2003, 22:02
Twitter: meon
Locatie: Bree
Uitgedeelde bedankjes: 574 keer
Bedankt: 770 keer

"ExcludeExplicitO365Endpoint" bestaat enkel vanaf Outlook 2016 en er zijn ook nog steeds 2013-clients.
Maar inderdaad, die setting ging ook meegenomen worden in de policy.
Plaats reactie

Terug naar “Development”