Noot van de redactie: Deze blog is oorspronkelijk gepubliceerd in april 2021 en is bijgewerkt naarmate de deadlines en details zijn veranderd. De meest recente update van november 2021 bevat aanvullende informatie over het verbod op HTTP-domeinvalidatie voor de uitgifte van subdomeinen en wildcards. Als u een GlobalSign-klant bent en vragen heeft over deze wijzigingen, kunt u onze supportsite bezoeken voor meer Help-artikelen en manieren om contact op te nemen.
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 398 dagen (ongeveer 13 maanden). In dit artikel willen we u op de hoogte brengen van enkele van de komende wijzigingen die door de Root-programma's en/of het CA/B Forum zijn doorgevoerd.
De HTTP-domeinvalidatiemethode verbieden voor de uitgifte van subdomeinen en wildcards
Deadline voor de industrie: 1 december 2021
Ingangsdatums GlobalSign:
GCC-klanten: 28 november 2021
Atlas-klanten: 30 november 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 met de HTTP-methode gevalideerd zijn, beperkt wordt tot de uitgifte van precies het gevalideerde domein. Met andere woorden, Wildcards en subdomein-SAN's zijn verboden voor domeinen die gevalideerd zijn 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.
Meer belangrijke details
Om naleving te garanderen, zal GlobalSign met ingang van 28 november (GCC-klanten) en 30 november (Atlas-klanten) het uitgeven van wildcard- of subdomein SAN-certificaten verbieden wanneer het domein is gevalideerd via de HTTP-domeinvalidatiemethode. Dit beleid geldt voor alle publiek vertrouwde TLS/SSL-certificaten en voor het Intranet SSL-product van GlobalSign.
Voorbeelden:
- Verbiedt de uitgifte van *.voorbeeld.com wanneer voorbeeld.com is gevalideerd via de HTTP-domeinvalidatiemethode.
- Verbiedt de uitgifte van www.voorbeeld.com wanneer voorbeeld.com is gevalideerd via de HTTP-domeinvalidatiemethode.
De HTTP-domeinvalidatiemethode kan worden gebruikt om de exacte SAN te valideren.
Voorbeelden:
- Als u www.voorbeeld.com valideert met de HTTP-domeinvalidatiemethode, dan kunt u www.voorbeeld.com opnemen in de SAN van het certificaat.
- Als u voorbeeld.com valideert met de HTTP-domeinvalidatiemethode, dan kunt u voorbeeld.com opnemen in de SAN van het certificaat.
Voor meer richtlijnen en aanbevelingen, zie ons supportartikel over dit onderwerp: Beleidswijzigingen HTTP-domeinvalidatiemethode.
De CA DIENT de domeinnamen en IP-adressen niet meer dan 398 dagen vóór de uitgifte van het certificaat te verifiëren
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 hergebruik 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 de vervaldatum 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.
Roterende ICA's met kortere intervallen
Tijdlijn: 24 augustus 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 driemaandelijks 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 24 augustus 2021.
- Vanaf 2022 zullen we de GlobalSign Atlas TLS CA's driemaandelijks 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 überhaupt 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 publiek vertrouwde TLS wordt door browsers en webservers gebruikt om TLS-sessies te ondersteunen ter bescherming van de eindgebruiker. Wij stellen altijd de veiligheid van de gebruikers van deze certificaten voorop bij onze overwegingen om nieuwe profielen of Issuing CA’s aan te maken. Er werd besloten dat de noodzaak van een sleutelovereenkomst bij 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 binnen een TLS-sessie moeten zijn. Om deze redenen werd de extensie geschrapt uit ons algemene TLS-aanbod. Klanten die aangepaste profielen nodig hebben voor tools en systemen buiten de grenzen van de traditionele browser-naar-server TLS-sessies zouden sterk moeten private trust sterk moeten overwegen.
Het gebruik van het OU-veld verbieden
Tijdlijn: 31 augustus 2022
Google maakt zich al lang zorgen over de manier waarop het OU-veld in TLS-certificaten wordt gevalideerd. De Baseline Requirements bevatten duidelijke vereisten voor alle onderwerpsvelden (C, S, L, Org, etc.) waarvoor de gegevens moeten worden verkregen uit een bedrijfsrepository; de vereiste voor het OU-veld blijft echter ongewijzigd:
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 door organisaties gebruikt 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. Ook deze wijziging gaat in op 31 augustus 2022.
Heeft u vragen? Bezoek onze supportwebsite voor meer informatie en manieren om contact op te nemen.
