NemID fik rutinemæssig fornyelse af certifikat galt i halsen

Nets DanID erkender, at onsdagens fejlramte NemID-certifikat burde have været fanget, inden det blev rullet ud.

Det var en planlagt, rutinemæssig fornyelse af det certifikat, som skal bevise, at NemID-appletten er lavet af Nets DanID og ikke tilfældige hackere, som gik galt natten til onsdag.

»Det er en kendt procedure. Når certifikatet udløber, så skal vi opdatere det,« siger pressechef Søren Winge fra Nets DanID til Version2.

Læs også: Natlig opdatering smadrer NemID-certifikat - Danske Bank skifter til nød-login

Certifikater til Java-appletter har en udløbsdato og skal derfor fornys regelmæssigt. Det skulle certifikatet for NemID-appletten også have været i nat, men noget gik galt undervejs.

»Noget gik galt i den kæde, så certifikatet kom ikke med fuldt ud. Derfor kunne Java ikke genkende os, og derfor kom Java med en advarsel,« siger Søren Winge.

NemID bruger en Java-applet, der er et lille program, som kan køres på brugerens pc via browseren. Det er ikke nødvendigt at signere alle Java-appletter, men NemID-appletten har brug for adgang til brugerens pc, og skal derfor bruge et certifikat. Ellers vil appletten kun kunne køre inden for en lukket sandkasse.

I forbindelse med en opdatering af certifikatet ville det være normalt, at brugeren fik en ny popup fra Java, men der ville stå Nets DanID som underskriver af certifikatet. Da signeringen gik galt, kom der blot til at 'Unknown' som underskriver, og derfor fik brugerne også en mere alvorlig sikkerhedsadvarsel fra Java.

Læs også: DanID's support: Se bort fra sikkerhedsadvarsel

»Det er en fejl fra vores side, som burde have været gennemtestet, inden det blev rullet ud i nat,« siger Søren Winge til Version2.

Nets DanID havde onsdag ved 14-tiden endnu ikke taget endelig stilling til, hvorvidt man skulle forsøge at rulle systemet tilbage til før opdateringen eller forsøge at rette fejlen uden at rulle tilbage.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Makholm Blogger

Nets DanID havde onsdag ved 14-tiden endnu ikke taget endelig stilling til, hvorvidt man skulle forsøge at rulle systemet tilbage til før opdateringen eller forsøge at rette fejlen uden at rulle tilbage.

Ehhh, i artiklen fra klokken 9:37 er Søren Winge ellers citeret for at man har taget beslutning om at rulle tilbage.

http://www.version2.dk/artikel/danid-vi-ruller-fejlramt-certifikat-tilba...

Casper Bang

Jeg skal på ingen måde forsvare DanID, men som ansvarlig for kode signering for det firma hvor jeg arbejder, ved jeg hvor tricky det kan være. Det er en delikat process, hvor en del ting kan gå galt. F.eks. har jeg set det før at Thawte piller lidt i CSR'en så det ikke længere passer i ens keystore og med det returnerede certifikat. Jeg vil gætte på af DanID har glemt at manuelt importere rod CA'er, det har man nemlig ikke skulle før i år.

Så igen, kære DanID, vil i ikke nok se at afskaffe dén skide applet hvis i vil ud til den brede befolkning. Vi skriver trods alt år 2012, ikke 1998!!

Casper Bang

Thawte er nu overgået [fra "Thawte Code Signing CA" og "Thawte Code Signing CA - G2"] til at bruge "Thawte Code Signing CA - G3" som umiddelbar parent i kæden. Dette synes ikke at være kendt af Java og bevirker at man får advarslen "...is not trusted. Install reply anyway? [no]:" under import med keytool, ligesom man får fejl når man signerer sine JAR filer.

Problemet kan (delvist) afværges ved at man indstallerer Thawte's Intermediate CA samt Cross Root CA i ens keystore, før man importerer sit udstedte certifikat. Alle certifikater skal importeres med flaget -trustcacerts, for at undgå fejl på køretid når signerede Java programmer køres. Det skriver Thawte naturligvis også i deres FAQ:
https://search.thawte.com/support/ssl-digital-certificates/index?page=co...

Bemærk at Linux JRE'er tilsyneladende er ude af stand til at validere kæden på trods af førnævnte flag, hvilket bevirker at man på Linux altid vil få en advarsel om at certifikatet ikke kunne verificeres.

Hvem sender jeg regningen til?

Leif Guldbrand

Har en konto hos LD (Lønmodtagernes Dyrtidsfond), som jeg på hverdage tjekker status på.
D. 14/3 loggede jeg ind med NemID og havde ingen problemer.
D. 15/3 loggede jeg ind med NemID og fik følgende fejl:

> <copy>
> This Connection is Untrusted
>
> You have asked Firefox to connect
> securely to idp.sikkeradgang.dk, but we can't confirm that your connection is secure.
> Normally, when you try to connect securely,
> sites will present trusted identification to prove that you are
> going to the right place. However, this site's identity can't be verified.
>
> What Should I Do?
>
> If you usually connect to
> this site without problems, this error could mean that someone is
> trying to impersonate the site, and you shouldn't continue.
> Technical Details
> idp.sikkeradgang.dk uses an invalid security certificate.
>
> The certificate is not trusted because the issuer certificate is not trusted.
>
> (Error code: sec_error_untrusted_issuer)
> </copy>

Kontaktede LD vedr. problemet - men har endnu ikke hørt fra dem vedr. en løsning. Sjovt nok havde jeg ingen problemer med mine to netbanker og med SKAT - som jeg lige testede med LogIn.

Der er ingen opdatering eller andet foretaget mellem de to dage.

Jens Dueholm Christensen

Thawte er nu overgået [fra "Thawte Code Signing CA" og "Thawte Code Signing CA - G2"] til at bruge "Thawte Code Signing CA - G3" som umiddelbar parent i kæden.

Nej, de anvender stadig deres G2 intermediate til udstedelser - jeg har for et par uger siden selv modtaget et signeret med G2 intermediate roden.

Bemærk at Linux JRE'er tilsyneladende er ude af stand til at validere kæden på trods af førnævnte flag, hvilket bevirker at man på Linux altid vil få en advarsel om at certifikatet ikke kunne verificeres.

Nej, det passer faktisk heller ikke.

Deres nuværende code signing certifikater til Java har denne rækkefølge (nederst i rækken er det certifikat man som kunde får leveret) - her benævnt med CN:

1: Thawte Premium Server CA
2: thawte Primary Root CA
3: Thawte Code Signing CA - G2
4: <udstedt certifikat til kunde>

SHA1 fingerprints for certifikaterne er:
1: E0:AB:05:94:20:72:54:93:05:60:62:02:36:70:F7:CD:2E:FC:66:66
2: 1F:A4:90:D1:D4:95:79:42:CD:23:54:5F:6E:82:3D:00:00:79:6E:A2
3: 80:8D:62:64:2B:7D:1C:4A:9A:83:FD:66:7F:7A:2A:9D:24:3F:B1:C7
4: <ukendt..>

Cert 1 er indeholdt i den ældste udgave af JRE'en jeg lige kunne finde nemt hos mig - her 1.6.0_20 som er fra april 2010 - og det ser ud til at den blev tilføjet Javas liste af betroede CA'er engang i december 2009.

Cert 2 og cert 3 er ganske rigtigt listet som 2 krævne intermediate CA'er man skal huske at importere i korrekte rækkefølge ind i den keystore man har sit eget certifikat liggende i - og derved kan kæden følges korrekt op til et certifikat Java stoler på.

Ved udstedelse af et code signing certifikat skriver Thawte da også følgende lige efter certifikatet:

INTERMEDIATE CERTIFICATE ADVISORY:
You MUST install the two Thawte intermediate certificates together with your Certificate on the computer you will be using to sign your code or it may not operate correctly.

Da jeg kiggede på den forfejlede opdatering tidligere i dag var det tydeligt at DanID / Nets ihvertfald ikke havde importeret disse 2 intermediate certifikater, da kun deres eget certifikat var synligt.

Når de så åbenbart ikke kan finde ud af at følge vejledningen fra udsteder kan man jo kun frygte hvad der ellers kan gå galt..

Jens Dueholm Christensen

F.eks. har jeg set det før at Thawte piller lidt i CSR'en så det ikke længere passer i ens keystore og med det returnerede certifikat.

Nu bliver jeg lidt nysgerrig..

Hvorfor skulle en ændring af oplysningerne i CSR'en påvirke keystoren og det certifikat du modtager fra dem?

Jo, den private nøgle dannes med et selvvalgt subject (CN, OU, O osv osv), men så længe det udstedte certifikat importeres ind i samme keystore igen under samme alias som blev brugt til at danne CSR'en (og hvorfor gøre andet?), så har jeg aldrig oplevet fejl eller problemer når det efterfølgende har været brugt.

Jeg vil gætte på af DanID har glemt at manuelt importere rod CA'er, det har man nemlig ikke skulle før i år.

Jo, i 2010 skulle man faktisk importere Thawtes "Thawte Code Signing CA" for at få et code signing certifikat til at virke korrekt. Det var - så vidt jeg kan gennemskue - et intermediate cert der var udstedt af "Thawte Premium Server CA" (cert 1 i min tidligere post).

Casper Bang

Cert 2 og cert 3 er ganske rigtigt listet som 2 krævne intermediate CA'er man skal huske at importere i korrekte rækkefølge ind i den keystore man har sit eget certifikat liggende i - og derved kan kæden følges korrekt op til et certifikat Java stoler på.


Fair nok, så det er ikke fordi de er gået over til G3 endnu. Problemet må udelukkende skyldes de manglende intermediates, som vi begge er inde på.

i 2010 skulle man faktisk importere Thawtes "Thawte Code Signing CA" for at få et code signing certifikat til at virke korrekt. Det var - så vidt jeg kan gennemskue - et intermediate cert der var udstedt af "Thawte Premium Server CA" (cert 1 i min tidligere post).

Det har jeg muligvis ikke haft gjort, da jeg sikkert har genbrugt min keystore fra året før. Jeg har håndteret certifikater de seneste 7 år, både hos GeoTrust og Thawte, og det var først i år man skulle de ekstra trin igennem som jeg linker til i mit oprindelige indlæg.

Nej, det passer faktisk heller ikke.

Jo det gør. Se hvon en valid certifikat, tager sig ud på Linux:
Fejlbesked
http://www.picvalley.net/u/1982/205479829715521826161332403849w6Jk1m6d0rvNigRb9XOK.PNG

Hvorfor skulle en ændring af oplysningerne i CSR'en påvirke keystoren og det certifikat du modtager fra dem?

Jeg har kun et gammelt notat i corporate wiki at støtte mig til, men det var noget med at under CSR genereringen havde jeg indtastet blankt for ST (State) da vi jo ikke har stater i DK. Da jeg havde problemer med import af det returnerede certifikat, og ringede til Thawte, fandt jeg ud af at de internt havde sat ST til "Herlev" (som jeg vil tro de har kopieret fra L (City). Der kan have været andre ting på spil, det er nogle år siden nu.

Leif Guldbrand

Sidste uge var den gal med NemID eller LD vedr. login,
men her d.d. er det igen ikke muligt at logge ind på
LD med brug af NemID.

Følgende fejl opstår - her d. 22/3-12 kl. 18:13
>Der er opstået en fejl
>Der er opstået et problem med siden, du besøgte.
>Fejlen er registret og vil blive undersøgt.

Jeg er ufatbar - med dette "sikkert" login system.

Log ind eller Opret konto for at kommentere