Ik denk dat de wereld er veiliger van wordt als we beestjes bij de naam noemen.

TLS certifcaten zijn hier niet het probleem (daar is niets geheim aan). Het probleem is dat als jouw organisatie een subdomein bij Zendesk huurt (dus organisatienaam.zendesk.com), en je voor TLS-verbindingen met dat subdomein een TLS-certificaat op naam van jouw organisatie wilt inzetten - en dus zelf moet aanschaffen (of gratis verkrijgen), je ook de (bij de public key in het certificaat horende) private key moet uploaden naar Zendesk.

Uit https://support.zendesk.com/hc/en-us/articles/203664356#topic_o5t_gnr_35:
De blunder hier is mogelijk dat Zendesk deze private keys, na installatie op de betreffende servers, niet op alle andere plaatsen heeft verwijderd.

Zou het niet zo kunnen zijn dat ze de database hebben gebruikt voor de kortstondige opslag van de TLS-encryptiesleutels en ze nu voor de zekerheid het advies hebben gegeven om het TLS-certificaat te vervangen? Better safe then sorry.

Wat ik bijzonderder vind is dat je dus mogelijk als organisatie een TLS-certificaat certificaat geüpload is welke 3 jaar geldig is... Dan heb je het als organisatie zijnde ook niet helemaal begrepen.

Ik heb geen idee, maar op z'n minst had Zendesk het systeem zo gemaakt dat een "binnenkomende" private key onmiddellijk wordt versleuteld voordat deze ergens wordt opgeslagen (in theorie zouden ze dit ook daadwerkelijk kunnen doen, maar dat lijkt me heel sterk - gezien het ontbreken van de security-awareness die ik verderop beschrijf, en ook het feit dat je er "al" na 3 jaar achter komt dat je server gehacked is/was). En niet met een symmetrische sleutel, maar met een public key van Zendesk, waarbij de bijbehorende private key ver uit de buurt van internet facing systemen wordt gehouden (ter herinnering: wat je met een public key van een asymmetrisch sleutelpaar versleutelt, hun je uitsluitend met de bijbehorende private key ontsleutelen).

Maar als de webserver gecompromitteerd is op het moment van ontvangst, helpt ook dat natuurlijk niet. Mijn punt is: private keys hoor je nooit onversleuteld te transporteren. En als je ze versleuteld transporteert, moet de decryptiesleutel er natuurlijk niet naast liggen (bij een versleutelde private key vraagt Zendesk je om ook het wachtwoord meteen en in dezelfde pagina te uploaden i.p.v. via een volledig gescheiden kanaal; met zo'n aanpak daalt mijn vertrouwen op voldoende security-awareness bij zo'n organisatie naar nul).

Zendesk kan het alleen correct doen door de klant te vragen om zijn server-private key, vóór transport, te versleutelen met een communicatie-public key van Zendesk. Helemaal fraai zou het zijn als Zendesk dat communicatie-sleutelpaar genereert op de doelserver, en -na ontvangst en decrypten van de server-private key- de communicatie-private key weggooit om "forward secrecy" te bewerkstelligen.

Als klant moet je wel zeker weten dat zo'n communicatie-public key echt van Zendesk is (en niet van een Man in the Middle). Als Zendesk die eenmalige communicatie-public key niet heeft gesigneerd met hun gangbare PGP e-mail key, of als je sowieso twijfelt: zodra je jouw -asymmetrisch versleutelde- server-private key uploadt, dubbel-check dan dat die server daadwerkelijk van Zendesk is (bij e-mail: dat de ontvanger daadwerkelijk een Zendesk e-mail adres heeft).

Maar ook dan geldt dat je er op moet kunnen vertrouwen dat in deze keten geen van de Zendesk systemen gecompromitteerd is, want dan liggen MitM mogelijkheden op de loer.

Certificaten zijn helaas een noodzakelijk gedrocht. Maar om elke 3 maanden een ander certificaat te installeren ?

Elk nadeel (veel te eenvoudig te verkrijgen Domain-Validated certificaten zoals van Let's Encrypt)
hep z' voordeel (de bedrieger heeft er maar 3 maanden iets aan).