Sundhed.dk har rod i certifikaterne

Den offentlige sundhedsportal sundhed.dk har problemer med sit sikkerhedscertifikat. Support-afdelingen skyder skylden på Windows Update.

»Websidens certifikat er ugyldigt. Vil du fortsætte?«

Denne besked rammer skærmen, når man som bruger af den offentlige sundhedsportal sundhed.dk forsøger at logge på med sin digitale signatur, eller hvis man går ind på den (angiveligt) sikre webside https://sundhed.dk.

Klikker man ned i detaljerne, fremgår det, at sitets sikkerhedscertifikat er udstedt af en virksomhed, som ikke kan stoles på. Til gengæld er certifikatet ikke udløbet.

Og går man helt ned i certifikat-detaljerne, kan man læse, at udstederen hedder TDC SSL Server CA.

Da Version2 kontakter sundhed.dk's support-afdeling, er det ikke et problem, de har hørt om før, og problemet foreslås afhjulpet ved at tilføje https://sundhed.dk i Internet Explorers liste over websteder, der er tillid til.

Dette står i grel kontrast til den besked, som Google Chrome disker op med, når man indtaster https://sundhed.dk:

»Du har forsøgt på at kontakte sundhed.dk, men i stedet har du fået kontakt med en server, der identificerer sig som *.sundhed.dk. Det kan skyldes en konfigurationsfejl på serveren eller noget andet og mere alvorligt. Det kan være en ondsindet part på dit netværk, som forsøger at få dig til at besøge en forfalsket (og potentielt skadelig) udgave af sundhed.dk. Du bør ikke fortsætte herfra,« advarer browseren.

Efter at have kontaktet kommunikationsafdelingen i Sundhed.dk bliver Version2 ringet op af incident supporter Bruno Brøsted. Han forklarer, at problemet skyldes, at Version2 ikke har installeret de nødvendige opdateringer fra Windows Update. Et hurtigt tjek blandt kolleger og eksterne bekendte viser dog, at alle de nævnte i givet fald mangler den pågældende opdatering.

Ifølge sundhed.dk støder support-afdelingen på dette problem mindre end én gang om ugen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Carsten Sørensen

Det er vel ikke så underligt, når der benyttes et stjernecertifikat.

Certifikatet påstår det hører til "*.sundhed.dk". Så skal det fejle, hvis man går ind på https://sundhed.dk. RFC 2818 siger at en stjerne matcher én domænekomponent, så *.sundhed.dk matcher www.sundhed.dk (som virker), men ikke sundhed.dk eller www.www.sundhed.dk.

Den forklaring Chrome giver er derfor helt korrekt.
IE8 på Vista giver den samme.

  • 0
  • 0
Mads Bendixen

At blande Windows Update ind i den sammenhæng er da helt ubegribelig.

Egentlig ikke. Der er jævnligt en opdatering af rodcertifikaterne på Windows Update (Under software, optional). I dette specifikke tilfælde hjælper det dog ikke at være fuldt opdateret.

  • 0
  • 0
Pascal Geuns

>Altså man kan ikke beskytte en side som https://sundhed.dk med et
>wildcardcertifikat til *.sundhed.dk - det virker selvfølgelig fint, hvis man går
>ind på https://www.sundhed.dk. Hvis de kunne skaffe et *.dk certifikat, så
>ville der jo ikke være problemer :-)

Det er ikke helt korrekt!

For at undgå disse problem, så sælger vi alle vores wildcard certifikater med et subject alternative name og dermed er det muligt at lave en SSL forbindelse til "basis" domænenavnet uden at browseren vil komme med en fejlmeldning.

Prøv for eksempel vores wildcard certifikat

https://secure.qualityssl.com/dk/ssl-test-page.lasso
https://qualityssl.com/dk/ssl-test-page.lasso

  • 0
  • 0
Lars Bjerregaard

For at undgå disse problem, så sælger vi alle vores wildcard certifikater med et subject alternative name og dermed er det muligt at lave en SSL forbindelse til "basis" domænenavnet uden at browseren vil komme med en fejlmeldning.

Så lærte jeg noget om stjerne-certifikater. Den metode i bruger der, er den "standardiseret"? Nævnt i RFC'en? Det lyder jo umiddelbart som den åbenlyst rigtige måde at gøre tingene på....

  • 0
  • 0
Pascal Geuns

Den metode i bruger der, er den "standardiseret"? Nævnt i RFC'en? Det lyder jo umiddelbart som den åbenlyst rigtige måde at gøre tingene på....

Ja, det er beskrevet i RFC 2469 under punkt 4.2.1.7.

Vi er pt. mig bekendt den eneste PBS godkende SSL certifikatudbyder som tilbyder dette feature.

Vi har det ikke kun på vore wildcard certifikater men også på vores standard "single domænenavn" certifikater.

http://www.qualityssl.com/dk/products/

  • 0
  • 0
Jeppe Toustrup

Problemet med deres wildcard certifikat kunne måske klares nemt med en ændret DNS opsætning hvis nu fx sundhed.dk bare var et CNAME for www.sundhed.dk i stedet for en A record.

Det vil ikke hjælpe noget. DNS og SSL certifikater til HTTPS har ingen sammenhæng. DNS hjælper blot klienterne med at få fat i den rigtige server IP adresse, og har ikke nogen viden omkring certifikater til HTTPS.

  • 0
  • 0
Carsten Sørensen

Ja, det er beskrevet i RFC 2469 under punkt 4.2.1.7.

Hmm, jeg tror at du har angivet en forkert RFC, kan du finde den rigtige?

Så vil jeg få tilføjet understøttelse for denne spidsfindighed i min egen kode, tak :)

  • 0
  • 0
Lars Bjerregaard

Ja, det er beskrevet i RFC 2469 under punkt 4.2.1.7.

Vi er pt. mig bekendt den eneste PBS godkende SSL certifikatudbyder som tilbyder dette feature.

Vi har det ikke kun på vore wildcard certifikater men også på vores standard "single domænenavn" certifikater.

Understøtter alle browsere denne metode?

  • 0
  • 0
Pascal Geuns

Understøtter alle browsere denne metode?

Det er lidt svært at utale sig om alle browser, men vi har testet det med de mest populære browser

IE 6 og senere
Firefox 2 og senere
Opera 9.5 og senere
Safari
Chrome

og disse browser viste vores testside korrekt uden problemer.

Du er velkommen til at teste andre browser med vores testside

https://qualityssl.com/dk/ssl-test-page.lasso

  • 0
  • 0
Kenneth Østrup

Det er korrekt. Dog kunne ændringen i DNS medfører at browserne venter med at initiere en SSL forbindelse indtil sundhed.dk var resolvet til www.sundhed.dk.

Anyway, den rigtige løsning er at tilføje sundhed.dk i en SubjectAlternativeName attribut i deres certifikat.

Ja, for man kan ikke lave "sundhed.dk" som CNAME record til "www.sundhed.dk" !

  • 0
  • 0
Pelle Ravn

Jeg kunne godt bruge noget hjælp med alt det der certifikat noget.

Jeg vil godt kunne bruge http://sundhed.dk på min computer og får (som nævnt i artiklen) den fejl med certifikatet, men har desværre et problem med at jeg ikke kan installere nye opdateringer fra Windows Update på min Mac OS X, som Sundhed.dks kommunikationsafdeling råder os til at gøre for at løse problemet.

Hvad gør jeg? PANIK!! :-D

  • 0
  • 0
Pascal Geuns

Hvad gør jeg? PANIK!! :-D

Pelle, du kan tage det stille og roligt, problemet skyldes ikke en manglede windows opdatering ;-)

Problemet skyldes at et standard wildcard certifikat ikke giver mulighed for at lave en korrekt SSL forbindelse med basis domænenavnet...

  • 0
  • 0
Pelle Ravn

Pelle, du kan tage det stille og roligt, problemet skyldes ikke en manglede windows opdatering ;-)

I know, der var en snært af ironi ind over det hele ;-) - Der manglede bare den detalje i artiklen at fejlen også kommer på andre OS'er. Syntes det er utroligt at diverse supportafdelinger bare går ud fra at vi alle sammen er én stor bunke tosser.

  • 0
  • 0
Sanne Rasmussen

Hejsa vil lige tilføje en bekræftelse på at årsagen til at https://sundhed.dk fejler er fordi de har et Wildcard SSL certifikat uden tilføjelsen af sundhed.dk som et SAN navn.

Det er dog efterhånden mere sjældent end normalt for certifikat udstedere at lave wildcard SSL uden SAN navnet med selve domænet, så det altså beskytter både *.sundhed.dk og sundhed.dk.

Vi fører f.eks. et PBS godkendt SSL Wildcard certifikat fra GlobalSign som inkluderer både * aliaset og selve domænet som SAN navn. Men det er ikke det eneste, f.eks. understøtter det meget billige AlphaSSL wildcard certifikatet også selve domænet med et SAN navn.

Begge produkter kan ses her https://www.fairssl.dk/certifikater/kategori/wildcard-ssl/

Derudover tror jeg at vi vil gøre sundhed.dk opmærksom på at de kan konkurrent fornye deres nuværende certifikat til et GlobalSign Wildcard SSL og få deres resterende udløbstid + 30 dage ekstra på et nyt certifikat gratis oven i den tid de køber :) Så må vi håbe de snart udskifter til noget der virker uanset hvad der bliver skrevet i adresse feltet :)

  • 0
  • 0
Log ind eller Opret konto for at kommentere