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

[meon]

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 (5.26 KiB) 843 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".

[Splitter]

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]

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.

[CCatalyst]

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.

[yaris]

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.

[CCatalyst]

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]

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)

[meon]

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.

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.

[meon]

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.

[Sasuke]

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

[meon]

"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.