Ondersteunde versies voor deze functie: Frontline Plus, Enterprise Plus, Education Fundamentals, Education Standard en Education Plus. Versies vergelijken
Gehoste S/MIME en versleuteling aan de clientzijde (VCZ) zijn Google Workspace-functies waarmee uw gebruikers S/MIME-e-mailberichten kunnen sturen en krijgen.
Google heeft certificaatvereisten en vertrouwde CA-certificaten voor S/MIME. Als uw certificaten niet aan deze vereisten voldoen, 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 je een extra rootcertificaat wilt accepteren, voeg je het toe in de Google Beheerdersconsole. Geef daarna minstens één domein op waarop het certificaat van toepassing is. Je kunt ook het versleutelingsniveau en het validatieprofiel van het certificaat aanpassen.
Ga naar Gehoste S/MIME aanzetten om berichten te versleutelen voor gedetailleerde stappen om S/MIME aan te zetten in Google Workspace. Ga naar Over versleuteling aan de clientzijde voor meer informatie over VCZ.
Op deze pagina
- 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 maar één rootcertificaat bevatten.
- De certificaatketen moet minstens één tussencertificaat bevatten.
- Elke certificaatketen moet een eindgebruikercertificaat hebben. Als er geen eindgebruikerscertificaat is toegevoegd, voert Google slechts de minimale verificatie uit.
- Het eindgebruikercertificaat mag niet de privésleutel bevatten.
Belangrijk: Er moet minstens 1 CA-tussencertificaat in de keten aanwezig zijn. 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 en klik 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 is niet beschikbaar voor gehoste S/MIME.
Meestal gebruiken organisaties één certificaat om berichten te ondertekenen en te versleutelen. Als uw organisatie verschillende certificaten vereist om berichten te ondertekenen en te versleutelen, gebruikt u de Gmail VCZ API om het openbare versleutelingscertificaat en het openbare ondertekeningscertificaat voor elke gebruiker te uploaden.
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.
De gebruikerscertificaten van beide domeinen 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 je 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 als dat 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 is het e-mailadres dat aan het certificaat van een gebruiker is gekoppeld, anders dan het primaire e-mailadres van de gebruiker. Het certificaat van Brandon Pham gebruikt bijvoorbeeld het e-mailadres b.pham@solarmora.com, maar Brandon gebruikt het adres brandon.pham@solarmora.com voor de meeste van zijn 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 er een certificaat niet overeenkomt. Dit kan worden veroorzaakt door een ongeautoriseerde of kwaadwillende gebruiker.
De optie Niet-overeenkomende certificaten toestaan is alleen beschikbaar met VCZ en niet met 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. Neem de uitgebreide stappen voor het toevoegen van rootcertificaten door.
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 certificaat van de gebruiker is gekoppeld, wordt niet opgeslagen in de contacten 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.
SHA-1 toestaan (niet aanbevolen)
Hoewel sommige e-mailclients SHA-1-gehashte handtekeningen toestaan, worden deze handtekeningen als niet-vertrouwd beschouwd. Dit komt omdat SHA-1 is beëindigd vanwege beveiligingsproblemen.
Als u een nieuw rootcertificaat toevoegt aan de instelling S/MIME, selecteert u de optie SHA-1 wereldwijd 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 u deze optie selecteert, vertrouwt Gmail S/MIME-certificaten die zijn bijgevoegd bij inkomende e-mails met SHA-1.
Problemen met het uploaden van certificaten oplossen
Als je problemen ondervindt bij het uploaden van certificaten, check je deze mogelijke oorzaken en probeer je 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 in de adreslijst te wijzigen. Als u bijvoorbeeld aangepaste certificaten heeft geüpload en berichten nog steeds als niet-vertrouwd worden behandeld, bewerkt u de lijst met toegestane domeinen van het certificaat.
Handtekening van certificaat is ongeldig
Controleer of het certificaat een geldige handtekening heeft en probeer het opnieuw te uploaden.
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.
Het certificaat bevat meerdere rootcertificaten
Je 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.
De 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 is misschien een probleem 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.