Kijk eens naar de datum van uitgifte

4 mei dodenherdenking. Maakt het mysterie niet minder voor mij. Het vorige certificaat was nog lang niet verlopen (22 september 2016)...

De sleutel hoeft helemaal niets anders te zijn. Het lijkt erop dat er twee verschillende CA's een certificaat hebben uitgegeven aan xs4all. Dit betekent dat onder andere de CN, CA en dergelijke verschillende zijn. De sleutel zou in theory echter wel hetzelfde kunnen zijn. Dit kan je ook gewoon met elkaar vergelijken.

De Sha1 Fingerprint is een hash van het gehele certificaat. Dus met de sleutel en alle informatie bij elkaar.

Het lijkt me overigens helemaal niet vreemd dat er een nieuw certificaat is uitgegeven voor de nieuwe webmail. Een certificaat is namelijk vaak verbonden aan een domeinnaam. Zo zou het kunnen dat het oude certificaat is uitgegeven voor mail.xs4all.com en het nieuwe voor mailv2.xs4all.com.

Snappie?

Ik gok dat xs4all risico's aan het verlagen is door wildcard certificaten bij twee verschillende CA's af te nemen:

- In het scenario dat één van die CA's gecompromitteerd raakt (zoals Diginotar vorig jaar) dan hebben alle xs4all SSL servers die certificaten ondertekend door de andere CA inzetten (ik vermoed de helft van hun SSL servers), geen probleem. Op de andere helft van hun servers kan xs4all, per server, dan volstaan met het vervangen van de private key en certificaat. Daarmee zijn ze niet meer afhankelijk van 1 enkele CA en hebben geen last van grote doorlooptijden bij het aanvragen van nieuwe certificaten!

- In het scenario dat een xs4all SSL server gecompromitteerd raakt, en niet kan worden uitgesloten dat de private key is gekopieerd, zullen ze het bijbehorende certificaat moeten intrekken. De consequentie daarvan is dat ze een probleem hebben op (vermoed ik) de helft van hun servers. Op die servers waarvan ze zeker weten dat deze niet gecompromitteerd zijn, kunnen ze weer het andere certificaat + private key installeren. Overigens zou het me niet verbazen als de private keys niet op de betreffende servers zelf staan maar in nagenoeg ontoegankelijke HSM's (zie http://en.wikipedia.org/wiki/Hardware_security_module) zijn ondergebracht, en daarmee het risico op dit scenario erg laag is.

Ik kan me niet voorstellen dat de aanschafkosten een grote rol hebben gespeeld bij de keuze voor wildcard certificaten (*.xs4all.nl) in plaats van unieke per-server certificaten. Aan de andere kant, door 2 wildcard certificaten te gebruiken, wordt het beheer er wel een stuk eenvoudiger door (je hebt maar 2 private keys en 2 certificaten en welk setje je op een server zet maakt niet uit). Een andere verklaring heb ik niet. Iemand anders wel misschien?

Tip voor beheerders met meerdere SSL servers die in principe van een wildcard certificaat gebruik zouden kunnen maken (ook al doen ze dat nu niet): zorg dat je altijd een wildcard certificaat (gebaseerd op een uniek keypair) van een andere CA op de plank hebt liggen. Gaat je eerste CA "titsup" (http://www.channelregister.co.uk/Tag/Titsup) dan ben je snel weer in de lucht met je wildcart cert!