Opmerking van de redactie: Deze blog is op 9 juni 2021 bijgewerkt met aanvullende informatie over de wijzigingen in het gebruik van ECC-sleutels en de gedachtegang erachter.
Het CA/Browser Forum en de Root-programma's specificeren vereisten waaraan CA's moet voldoen en waarop ze gecontroleerd moeten worden om uniforme vereisten voor alle CA's te bieden en om websitebezoekers te beschermen door belangrijke nalevings- en beveiligingsvereisten vast te stellen. U weet allemaal dat de maximale geldigheidsduur voor TLS-certificaten is teruggebracht van 5 jaar tot 3 jaar, tot 825 dagen en afgelopen september tot nog maar 397 dagen (ongeveer 13 maanden). In dit artikel willen we u op de hoogte brengen van enkele van de aankomende wijzigingen die door de Root-programma's en/of het CA/B Forum zijn doorgevoerd.
De CA controleert de domeinnamen en IP-adressen niet meer dan 398 dagen vóór de uitgifte van het certificaat
Ingangsdatum: 1 oktober 2021
Afgelopen september stelde Apple een maximale geldigheidsduur van 398 dagen verplicht, maar de hergebruiksperiode voor domein- en organisatievalidatie bleef op 825 dagen staan. Dit is de tweede stap op weg naar die verandering. Deze verkorting van de termijn voor het gebruik van domeinen werd verwacht en zal waarschijnlijk niet de laatste zijn. Dit vloeit voort uit verschillende onderzoeken die hebben aangetoond dat in bepaalde gevallen, bij verandering van eigenaar van domeinen, de bestaande certificaten nog steeds kunnen worden vervangen/opnieuw uitgegeven door de vorige CA. Een manier om dat te verhelpen is de hergebruiksperiode voor domeinvalidatie te verkorten.
Neem een stap terug en bekijk de situatie op deze manier:
- Tot de door Apple voorgeschreven verkorting van de maximale geldigheidsduur bedroeg de tijd tussen domeinvalidatie en de vervaldatum van het certificaat 825 + 825 dagen, ofwel ongeveer 4,5 jaar. Dat is een lange tijd!
- Met de verkorting van de maximale geldigheid door Apple is het verschil 825 + 398 dagen, wat nog steeds meer dan 3 jaar is.
- Met deze laatste wijziging is het maximale verschil 398 + 398, of iets meer dan 2 jaar.
- Ter vergelijking: de CA die de meeste certificaten per jaar uitgeeft, Let’s Encrypt, geeft certificaten uit met een maximale geldigheidsduur van 90 dagen en hergebruikt domeinvalidatie voor maximaal 30 dagen, of maximaal 4 maanden tussen de validatie en het verlopen van het certificaat.
We kunnen verwachten dat de industrie zich zal richten op de uitgangswaarde van Let’s Encrypt en uiteindelijk zelfs korter dan dat.
De HTTP-domeinvalidatiemethode verbieden voor de uitgifte van subdomeinen en wildcards
Ingangsdatum: 1 december 2021
De HTTP-domeinvalidatiemethode (officieel bekend als methode 6, Agreed-Upon Change to Website) wordt gewoonlijk gebruikt om de domeincontrole te verifiëren. Als u een bestand in een specifieke directory van de website kunt plaatsen, toont u daarmee de controle over dat domein aan. In tegenstelling tot DNS hebben websites niet dezelfde controles waarbij er een formele overdracht van machtigingen van het domein naar subdomeinen is. Dus als voorbeeld.com gehackt is, of als de eigenaar bepaalde kwaadaardige bedoelingen had, dan kunnen ze voorbeeld.com goedkeuren en vervolgens certificaten uitgeven voor subdomeinen. Maar die subdomeinen kunnen verschillende entiteiten zijn, en opnieuw, aangezien er niet hetzelfde niveau van formele overdracht van controle is, verplicht Mozilla dat de uitgifte van certificaten die domeinen bevatten die zijn gevalideerd met de HTTP-methode beperkt blijft tot de uitgifte van precies het gevalideerde domein. Met andere woorden, Wildcards en subdomein-SAN's zijn verboden voor domeinen die zijn gevalideerd met de HTTP-methode.
Dit heeft gevolgen voor klanten omdat het een gangbare methode is om domeinvalidatie uit te voeren. Als u deze methode wilt blijven gebruiken, moet u elke SAN:DNSName afzonderlijk valideren.
Roterende ICA's met kortere intervallen
Tijdlijn: 13 juli 2021 en vervolgens driemaandelijks in 2022
GlobalSign zal beginnen met het roteren van onze Atlas TLS CA’s op een geplande basis om een goede beveiliging en flexibiliteit van het ecosysteem te bevorderen. In het verleden hebben we CA’s opgezet en vele jaren gebruikt, maar er zijn veel redenen om dit tijdsinterval te verkorten. Door de duur van het gebruik van CA’s te verkorten, bereiken we de volgende voordelen:
- Dit beperkt het aantal certificaten dat door een enkele CA wordt uitgegeven en de bijbehorende private key, wat onze eigen crypto-flexibiliteit verbetert.
- Dit beperkt de impact als er een probleem is met de integriteit, naleving of beveiliging van de CA.
- Hierdoor wordt de omvang van de CRL's kleiner, wat de validatieprestaties ten goede komt.
- Dit leert onze klanten om onmiddellijke CA-vervangingen te verwachten en te plannen, wat hun crypto-flexibiliteit vergroot.
- In ons definitieve plan zullen alle Atlas TLS CA's van GlobalSign elk kwartaal en alle Atlas TLS CA's van de klant jaarlijks worden geroteerd.
- De eerste rotatie van de GlobalSign Atlas TLS CA voor 2021 vindt plaats op 13 juli 2021.
- Vanaf 2022 zullen we de GlobalSign Atlas TLS CA's elk kwartaal bijwerken, op de tweede maandag van het kwartaal, en zullen we de klantspecifieke Atlas TLS CA's elk jaar in januari bijwerken.
Gevolgen en aanbevelingen:
- Klanten moeten altijd bereid zijn om nieuwe CA's te accepteren wanneer ze nieuwe TLS-certificaten installeren. De CA die het certificaat heeft uitgegeven, is beschikbaar in de API en moet worden gebruikt bij het downloaden van het certificaat, zodat de huidige CA altijd voorzien is van het uitgegeven certificaat.
- Klanten MOGEN geen public key vastpinnen op CA-certificaten en we raden het ten zeerste af om public keys helemaal vast te pinnen, omdat dat het doel van crypto-flexibiliteit voorbijschiet.
- We moedigen klanten aan om flexibele procedures voor Issuing CA’s te volgen en altijd de meegeleverde ICA te downloaden en te installeren bij het aanschaffen van nieuwe certificaten.
- Meld u hier aan voor belangrijke updates op de statuspagina van GlobalSign - https://status.globalsign.com/
Meer informatie vindt u op onze supportwebsite.
Wijzigingen in het gebruik van ECC-sleutels
Ingangsdatum: 26 juli 2021
We gaan het gebruik van sleutels in onze ECC TLS-certificaten wijzigen om ze af te stemmen op de best practices in de sector en met de wijzigingen in de CA/B Forum Baseline Requirements die momenteel worden doorgevoerd. Momenteel nemen we zowel digitale handtekeningen als sleutelovereenkomsten op, maar vanaf deze datum zullen we alleen digitale handtekeningen opnemen.
Onze public trust TLS wordt gebruikt door browsers en webservers om TLS-sessies te ondersteunen voor de bescherming van eindgebruikers. We zullen de veiligheid van de gebruikers van deze certificaten altijd voorop houden in onze overwegingen bij het aanmaken van nieuwe profielen of het uitgeven van CA's. Er werd besloten dat de noodzaak van Key Agreement in het gebruik van ECC-certificaten niet langer nodig was binnen een TLS-certificaat, terwijl het ook potentiële veiligheidsproblemen voor eindgebruikers introduceerde omdat de ondertekeningssleutel en de encryptiesleutel afzonderlijke sleutels zouden moeten zijn binnen een TLS-sessie. Om deze redenen werd de uitbreiding geschrapt uit ons algemene TLS-aanbod. Klanten die aangepaste profielen nodig hebben voor tools en systemen buiten de grenzen van traditionele browser-naar-server TLS-sessies, zouden sterk moeten overwegen om private trust aan te bieden.
Het gebruik van het OU-veld verbieden
Tijdlijn: TB
Google maakt zich al lang zorgen over de manier waarop het OU-veld in TLS-certificaten wordt gevalideerd. De Baseline Requirements hebben duidelijke vereisten voor alle onderwerpsvelden (C, S, L, Org, enz.) waarvoor de gegevens moeten worden verkregen uit een bedrijfsrepository; de vereiste voor het OU-veld blijft echter als volgt:
De CA dient een proces te implementeren dat voorkomt dat een OU-attribuut een naam, DBA, handelsnaam, handelsmerk, adres, locatie of andere tekst bevat die verwijst naar een specifieke natuurlijke persoon of juridische entiteit, tenzij de CA deze informatie heeft geverifieerd.
Hierdoor kunnen klanten niet-gevalideerde en mogelijk misleidende informatie verstrekken waarop (onbedoeld) kan worden vertrouwd. Google pleit dan ook met klem voor de verwijdering van het veld.
Dit veld wordt vaak gebruikt door organisaties om hen te helpen bij het beheer van de certificaten door de afdeling aan te geven waartoe het certificaat behoort. Certificaatrapportage helpt de organisatie bij het toewijzen van verlengingen en vervangingen op basis van dit veld; het doel van de gegevens in certificaten is echter voor afhankelijke partijen, die de site bezoeken en een beslissing willen nemen over het al dan niet vertrouwen van de site en niet voor het certificaatbeheer van de organisatie.
Klanten moeten zich bewust zijn van deze komende verandering en rekening houden met de afschaffing van het OU-veld. Hoewel er geen datum is vastgesteld, zullen we het algemene gebruik van het OU-veld in de komende maanden geleidelijk afschaffen en informatie verzamelen voor de root-programma's over waarom sommigen het OU-veld nodig blijven hebben.
Heeft u vragen? Bezoek onze supportwebsite voor meer informatie en manieren om contact op te nemen.
