Deze functie wordt ondersteund in de volgende versies: Frontline Plus, Enterprise Plus, Education Fundamentals, Education Standard, Teaching and Learning Upgrade en Education Plus. Versies vergelijken
Gehoste S/MIME en versleuteling aan de clientzijde (VCZ) zijn Google Workspace-functies waarmee uw gebruikers S/MIME-mails kunnen sturen en krijgen.
Google heeft certificaatvereisten en vertrouwde CA-certificaten voor S/MIME. Als uw certificaten niet voldoen aan deze vereisten, merkt u misschien dat bepaalde berichten niet worden vertrouwd. U kunt dit oplossen door andere rootcertificaten te accepteren van rootcertificeringsinstanties (CA's) die u vertrouwt.
Als u een aanvullend rootcertificaat wilt accepteren, moet u dit toevoegen in de Google Beheerdersconsole. Voer daarna minstens één domein in waarop het certificaat van toepassing is. Optioneel kunt u ook het versleutelingsniveau en het validatieprofiel van het certificaat aanpassen.
Ga naar Gehoste S/MIME aanzetten om berichten te versleutelen voor uitgebreide stappen om S/MIME aan te zetten in Google Workspace. Ga naar Over versleuteling aan de clientzijde voor meer informatie over VCZ.
- Richtlijnen voor rootcertificaten
- Het domein van een rootcertificaat wijzigen
- Een rootcertificaat verwijderen
- S/MIME-berichten uitwisselen tussen domeinen
- Verschillende certificaten gebruiken voor ondertekening en versleuteling
- Toestaan dat het certificaat niet overeenkomt (niet aanbevolen)
- SHA-1 toestaan (niet aanbevolen)
- Problemen met het uploaden van rootcertificaten oplossen
Richtlijnen voor rootcertificaten
Rootcertificaten moeten voldoen aan deze richtlijnen om te worden gebruikt met S/MIME in Google Workspace:
- Het certificaat moet de indeling .pem hebben en mag slechts één rootcertificaat bevatten.
- De certificaatketen moet minstens één tussencertificaat bevatten.
- Elke certificaatketen moet een eindgebruikercertificaat hebben. Als er geen eindgebruikercertificaat is toegevoegd, voert Google slechts de minimale verificatie uit.
- Het eindgebruikercertificaat mag niet de privésleutel bevatten.
Belangrijk: Er moet zich minstens 1 CA-tussencertificaat in de keten bevinden. De root-CA mag dus niet rechtstreeks eindgebruikercertificaten uitgeven.
Het domein van een rootcertificaat wijzigen
U kunt de vervaldatum van een certificaat niet bewerken, ook niet om een certificaat te vervangen. U moet het certificaat verwijderen en een nieuw certificaat uploaden. Als u een rootcertificaat verwijdert, heeft dit geen invloed op al geüploade eindgebruikercertificaten.
Zo wijzigt u het domein van een rootcertificaat:
- Ga in de Google Beheerdersconsole naar de instelling S/MIME op het tabblad Gebruikersinstellingen.
- Selecteer in de tabel met aanvullende rootcertificaten het certificaat dat u wilt wijzigen. Klik vervolgens op Bewerken.
- Update het domein en klik op Opslaan.
Een rootcertificaat verwijderen
Zo verwijdert u een rootcertificaat:
- Ga in de Google Beheerdersconsole naar de instelling S/MIME op het tabblad Gebruikersinstellingen.
- Selecteer in de tabel met aanvullende rootcertificaten het certificaat dat u wilt verwijderen en klik op Verwijderen.
Verschillende certificaten gebruiken voor ondertekening en versleuteling
Deze functie is alleen beschikbaar bij VCZ. De functie wordt niet ondersteund voor gehoste S/MIME.
Organisaties gebruiken meestal één certificaat om berichten te ondertekenen en te versleutelen. Als uw organisatie echter verschillende certificaten vereist om berichten te ondertekenen en te versleutelen, gebruikt u de Gmail VCZ API om het openbare certificaat voor versleuteling en het openbare certificaat voor handtekeningen te uploaden voor elke gebruiker.
Ontdek meer informatie over hoe u de Gmail VCZ API gebruikt om gebruikerscertificaten te beheren.
S/MIME-berichten uitwisselen tussen domeinen
Als u wilt dat mensen in verschillende domeinen S/MIME-berichten kunnen uitwisselen, moet u misschien een paar extra stappen uitvoeren in de Google Beheerdersconsole. Volg de aanbevolen stappen hieronder, afhankelijk van hoe de gebruikerscertificaten worden uitgegeven voor het domein.
- Beide gebruikerscertificaten worden uitgegeven door een vertrouwde root-CA: Als alle gebruikerscertificaten in beide domeinen worden uitgegeven door een root-CA die wordt vertrouwd door Google, hoeft u geen extra stappen uit te voeren. Deze root-CA-certificaten worden altijd vertrouwd door Gmail.
- Beide gebruikerscertificaten worden uitgegeven door dezelfde niet-vertrouwde root-CA: In dit geval heeft een niet-vertrouwde root-CA de gebruikerscertificaten uitgegeven voor je domein en het domein waarmee u S/MIME-berichten wilt uitwisselen.
Voeg de niet-vertrouwde root-CA toe in de Google Beheerdersconsole volgens de stappen in Gehoste S/MIME aanzetten. Vul in het vak Rootcertificaat toevoegen het andere domein in het veld Adreslijst in.
- De gebruikerscertificaten van een domein worden uitgegeven door een niet-vertrouwde root-CA: In dit geval worden de gebruikerscertificaten van een domein uitgegeven door een niet-vertrouwde root-CA. De gebruikerscertificaten van het andere domein worden uitgegeven door een andere root-CA.
Voeg de root-CA van het andere domein toe in de Google Beheerdersconsole volgens de stappen in Gehoste S/MIME aanzetten. Vul in het vak Rootcertificaat toevoegen het andere domein in het veld Adreslijst in.
Alleen gebruiken wanneer het nodig is
Gebruik de certificaatopties in dit gedeelte alleen als dat echt nodig is en zorg dat u de mogelijke gevolgen van het gebruik ervan begrijpt. Toestaan dat het certificaat niet overeenkomt (niet aanbevolen)Soms kan het e-mailadres dat aan het certificaat van een gebruiker is gekoppeld, afwijken van het primaire e-mailadres van de gebruiker. Het certificaat van Brandon Pham gebruikt bijvoorbeeld het e-mailadres [email protected], maar Brandon gebruikt het adres [email protected] voor de meeste werkmails. Dit is wat met niet-overeenkomende certificaten wordt bedoeld.
Belangrijk: Om veiligheidsredenen raadt Google aan niet-overeenkomende certificaten alleen toe te staan als deze functie vereist is door uw organisatie. Als deze optie aanstaat, krijgen gebruikers en beheerders geen waarschuwing als het certificaat niet overeenkomt, wat kan worden veroorzaakt door een ongeautoriseerde of kwaadwillende gebruiker.
De optie Toestaan dat certificaten niet overeenkomen is alleen beschikbaar voor VCZ, niet voor gehoste S/MIME. Als u VCZ wilt instellen zodat certificaten niet hoeven overeen te komen, selecteert u de optie voor niet-overeenkomende certificaten als u rootcertificaten toevoegt in de instelling voor gehoste S/MIME. Bekijk de uitgebreide stappen voor rootcertificaten toevoegen.
Als de optie Toestaan dat het certificaat niet overeenkomt is geselecteerd, kunnen ontvangers inkomende berichten met een niet-overeenkomend certificaat ontsleutelen en lezen. Eerdere berichten met een certificaat dat niet overeenkomt (ontvangen voordat de instelling werd aangezet) kunnen ook worden gedecodeerd en gelezen. Het e-mailadres dat aan het gebruikerscertificaat is gekoppeld, wordt echter niet opgeslagen in de contactpersonen van de ontvanger. Gebruik Google Cloud Directory Sync om e-mailadressen te synchroniseren en op te slaan.
De optie Toestaan dat het certificaat niet overeenkomt werkt alleen voor interne contacten of contacten die zijn gesynchroniseerd met GCDS. De functie werkt niet voor externe contacten.
Hoewel sommige e-mailclients toestaan dat SHA-1 gehashte handtekeningen worden gebruikt, lijken deze handtekeningen niet vertrouwd. Dit komt omdat SHA-1 is beëindigd vanwege beveiligingsproblemen.
Wanneer u een nieuw rootcertificaat toevoegt aan de instelling S/MIME, selecteert u de optie SHA-1 globaal toestaan alleen als:
- als uw organisatie berichten stuurt met de cryptografische hash-functie van SHA-1 voor S/MIME-berichtbeveiliging en
- u wilt dat deze berichten worden vertrouwd.
Als deze optie is geselecteerd, vertrouwt Gmail S/MIME-certificaten die met SHA-1 bij inkomende e-mails zijn bijgevoegd.
Problemen met het uploaden van certificaten oplossen
Als u problemen ondervindt bij het uploaden van certificaten, controleert u deze mogelijke oorzaken en probeert u de aanbevolen oplossingen:
Certificaat voldoet niet aan de minimum vereisten om te worden vertrouwd
Controleer of het certificaat niet zelfondertekend is, of het niet is ingetrokken en of de sleutellengte 1024 bits of meer is. Probeer het certificaat daarna opnieuw te uploaden.
Bewerk het certificaat om de domeinen op de adreslijst te wijzigen. Als u bijvoorbeeld aangepaste certificaten heeft geüpload en de berichten nog steeds als niet-vertrouwd worden behandeld, kunt u proberen de lijst met toegestane domeinen van het certificaat te bewerken.
Handtekening van certificaat is ongeldig
Controleer of het certificaat een geldige handtekening bevat en probeer het opnieuw.
Verlopen certificaat
Controleer of de datum op het certificaat binnen de periode valt die is ingevoerd in de velden Niet voor (datum) en Niet na (datum). Probeer het certificaat daarna opnieuw te uploaden.
Certificaatketen bevat minstens één ongeldig certificaat
Controleer of het certificaat de juiste indeling heeft en probeer het uploaden opnieuw.
Certificaat bevat meerdere rootcertificaten
U kunt geen certificaat uploaden dat meer dan één rootcertificaat bevat. Controleer of het certificaat slechts één rootcertificaat heeft en probeer het uploaden opnieuw.
Certificaat kan niet worden geparseerd
Controleer of het certificaat de juiste indeling heeft en probeer het uploaden opnieuw.
Server retourneert een onbekende reactie
Controleer of het certificaat de juiste indeling heeft en probeer het uploaden opnieuw.
Certificaat kan niet worden geüpload
Er kan een probleem zijn opgetreden bij het verbinden met de server. Dit is meestal een tijdelijk probleem. Wacht enkele minuten en probeer opnieuw te uploaden. Als het uploaden blijft mislukken, controleert u of het certificaat de juiste indeling heeft.
