Udløbet SSL-certifikat sendte Ingeniøren og Version2 i sort

19. januar 2018 kl. 14:4517
Udløbet SSL-certifikat sendte Ingeniøren og Version2 i sort
Illustration: screenshot.
Der har været problemer med at tilgå Ingeniørens og Version2's hjemmesider på grund af et udløbet SSL-certifikat.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

I knapt ti timer har der været problemer med at tilgå Mediehuset Ingeniørens digitale medier på ing.dk og version2.dk

Forklaringen skulle være, at leverandøren, som hoster Mediehusets sites, er blevet købt af et andet selskab, og i den forbindelse har der ikke været styr på alle processer.

På den måde havnede en mail om, at certifikaterne skulle fornys ikke det rigtige sted.

»Mail om husk-at-forny blev desværre ikke videresendt til ny support,« oplyser it-chef i Mediehuset Ingeniøren Jesper Bille Haun via mail.

Artiklen fortsætter efter annoncen

Da certifikatet ikke blev fornyet, betød det at browsere brokkede sig over, at certifikatet ikke længere var gyldigt, og brugere fik derfor problemer med at tilgå hjemmesiderne.

Problemerne stod på i tidsrummet fra midnat 19. januar frem til 09:46 samme dag, hvor et nyt og gyldigt certifikat blev lagt på.

For at undgå, at noget tilsvarende gentager sig, kommer der fremadrettet ekstra fokus på overvågningen.

»Leverandør sørger for at sikre, at disse mails bliver samlet op - og vi har sat ekstra overvågning op hos os selv,« oplyser Jesper Bille Haun.

HSTS

Alt efter hvilken browser, der er blevet anvendt, kan det have været mere eller mindre vanskeligt at tilgå hjemmesiderne. Adgang til siderne er øjensynligt blevet særlig vanskeliggjort af det, der kaldes HTTP Strict Transport Security (HSTS).

Det var i denne skribents tilfælde således ikke umiddelbart muligt at tilgå Version2.dk via Google Chrome-browser, der gav følgende besked.

»You cannot visit www.version2.dk right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.«

Det forlyder, at folk (det vil sige omkringværende kollegaer på redaktionen) har haft mere succes med at tilgå hjemmesiderne via Microsofts Edge-browser.

HTTP Strict Transport Security (HSTS) - som altså er aktiveret på Version2.dk - er ifølge Wikipedia en web-sikkerhedspolitik, som beskytter hjemmesider mod nedgraderingsangreb i forhold til den anvendte protokol, samt cookie-hijacking. Når HSTS anvendes, fortæller web-serveren ifølge udlægningen fra det åbne online-leksikon, at browseren kun skal kommunikere med serveren via HTTPS

17 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
18
21. januar 2018 kl. 14:57

Hos en professionel leverandør vil certifikathåndtering håndteres uden email til specifikke medarbejdere eller fællespostkasser. Risikoen for at bolden falder ned mellem to stole er for stor. I hvert fald i en reguleret branche. Det er sagen her et godt eksempel på. En overdragelse har fordret at incidentet fik lov at opstå.

Certifikater bør styres et centralt sted og et moderne sted vil de fleste decentrale certifikater udskiftes automatisk uden behov for interaktion med menneske ud over en 'certifikat udskiftet ok' til ack køen i overvågning..

https://www.venafi.com/solutions for eksempel har værktøjer til håndtering af store mængder certifikater.

Fornyelsen skal ske proaktivt ud fra et skema, det aktivt tildeler en opgave til en afdeling, der har rette adgange og kompetencer, skulle det alligevel ske manuelt. Visse brancher er nok ikke store nok til at automatisk udskiftning giver værdi. De udfører skiftet så systemet automatisk tager nyt i brug på udløbsdato. Hvis der er afhængigheder til eksterne partnere er opgaven endnu mere under behov for processer.

Dernæst, hvis det alligevel glipper, skal overvågningsværktøjet samle warning op i eventloggen hvor det alligevel logges som advarsler. SCOM f.eks samler op første gang 20 dage før udløb svjh. Dernæst assigne til en operativ afdeling der sidder med incidenthåndtering. Over dagene frem til udløb skal prioriteten stige.

Alternativt er et major incident som denne artikel egentlig omhandler (afbrydelse af service i længere tid), og man kan kun gisne om hvilke andre sites der blev ramt.

Når det så er sagt er det også uprofessionelt at lave en artikel om at ens leverandør eller dennes underpinnings har trådt i spinaten. Grundlæggende er det mediets eget ansvar at sikre den rette kontrakt for at drive service effektivt.

Men. IT branchen er jo også den mindst modne. Jeg føler mig ret overbevist om at produktionsvirksomheder for længst har processer for sådan noget og bliver målt herpå. Lufthavne, flyproducenter, fabrikker, hvor hvert minuts udetid koster kassen, bare for at nævne nogen.

Special report. Jow.

17
21. januar 2018 kl. 09:24

Endnu et eksempel med nagios, det er testet kode så man kan rimeligt regne med det, OG blot for en sikkerheds skyld kan man sætte critical days til 10000, så får man en fejl som viser at checket virker

Usage: check_ssl_cert -H host [OPTIONS] -c,--critical days minimum number of days a certificate has to be valid to issue a critical status

Ethvert hosting firma burde have det kørende mod alle de domæner det hoster. Simpelt og generisk.

16
21. januar 2018 kl. 02:13

Så er det hellere ikke værre. De var nede i 7 timer og 46 minutter svarende til en oppetid på 99,9% på årsbasis. Og det meste af nedetiden lå om natten.

Vi ved ikke hvilken SLA der gælder. Men en seriøs hosting leverandør vil tage sig betalt for en SLA der giver bedre garanti end dette. Så er vi ude i redundante systemer og døgnovervågning med tilkaldevagt med mere.

Det særlige ved sagen er at den kunne være undgået med bedre overvågning. Men det kan man sige om de fleste fejl hvor det menneskelige element indgår. Jeg vil som kunde være tilfreds, hvis leverandøren meddeler at de har lært af fejlen, og har taget skridt til at forhindre en gentagelse.

15
20. januar 2018 kl. 18:37

og når det sker så reducere det chancen for fejl næste gang

13
19. januar 2018 kl. 19:18

Du afspejler netop denne form får ansvarsfraskrivelse, som jeg indirekte beskrev. Som kunde er man i sidste ende altid selv ansvarlig for sine ting. Man har selv ansvaret for, at det arbejde man beder andre om at udføre også bliver udført korrekt.

Du afspejler til gengæld den fraskrivelse af ansvar som er typisk for leverandører i IT-branchen.

Som kunde kan jeg forvente at den vare jeg køber fungerer, det kan jeg i alle andre brancher og det vil VIRKELIGT pynte på IT branchen, hvis de tog sig sammen og fik begrebet leverandøransvar på plads.

12
19. januar 2018 kl. 18:34

En dygtig kunde, måler på om leverandøren leverer det forventede, fx ved at kontrollere oppetid, svartid og ssl cert udløb, når der er tale om websites.

11
19. januar 2018 kl. 17:57

Du afspejler netop denne form får ansvarsfraskrivelse, som jeg indirekte beskrev. Som kunde er man i sidste ende altid selv ansvarlig for sine ting. Man har selv ansvaret for, at det arbejde man beder andre om at udføre også bliver udført korrekt.

9
19. januar 2018 kl. 17:09

Men er jeg den eneste der kan se det komiske i at en glimrende nyheds site som også beskæftigere sig med sikkerhed hvor noget så simpel at opdatere en SSL certifikat ??

8
19. januar 2018 kl. 16:48

Skægt som det altid er andres skyld, når noget går galt.

7
19. januar 2018 kl. 16:36

Og når det så udløber alligevel og man ikke fik nogen email, var det fordi der var en bug i cronjobbet. :-)

En integrering med eksisterende overvågning er at foretrække. Her er et eksempel med Nagios:
  1. $ check_http --ssl -C 30,14 -H <a href="http://www.version2.dk">www.version2.dk</a>
  2. OK - Certificate 'ing.dk' will expire on Mon 18 Jan 2021 11:59:59 PM GMT +0000.

Nu er der selvfølgelig længe til 2021. Og det er så en af de andre foredele ved Letsenscrypt: Det er hver tredje måned, så du ved at det skal overvåges.

6
19. januar 2018 kl. 16:23

På mit arbejde bruger vi Let's Encrypt, og det er så nemt at benytte at det er ligefør det er skræmmende. Plus det er gratis.

Vi plejer at lave en reminder første gang et certifikat skal fornyes for at sikre vores opsætning er korrekt og forudsat alt går godt med fornyelsen, hvilket den forsøger at gøre automatisk af sig selv 1 måned før det gamle udløber, så passer det sig selv derfra.

5
19. januar 2018 kl. 16:17

Og når det så udløber alligevel og man ikke fik nogen email, var det fordi der var en bug i cronjobbet. :-)

4
19. januar 2018 kl. 16:06

Hvad med et alm. cronjob som checker hver nat og hvis der er 2 uger til at det løber ude; sender en mail den ansvarlige ... der er sådan man gør ude i den rigtige verden ;-)

3
19. januar 2018 kl. 15:49

Aiii det er næsten for lavteknologisk!

2
19. januar 2018 kl. 15:43

F.eks en til to uger før udløb !

1
19. januar 2018 kl. 15:39

Hvad med at skrive udløbsdatoen ind i kalenderen ?