CipherTrust Manager Web Interface Certificaatfout

Gepubliceerd: april 2023. Bijgewerkt: augustus 2026. Beoordeeld door het Key Management Advisory-team van Encryption Consulting.

Een CipherTrust Manager- implementatie vormt het controlepaneel voor de encryptiesleutels van een organisatie, waardoor een browserwaarschuwing op de eigen webinterface doorgaans snel de aandacht trekt. Deze handleiding beschrijft de oorzaak van de certificaatfout in de CipherTrust Manager-webinterface, hoe u deze kunt verhelpen en hoe u ervoor kunt zorgen dat dit niet langer als een eenmalige taak wordt beschouwd. U kunt dit certificaat dus dezelfde levenscyclusdiscipline geven als elk ander certificaat dat een administratieve interface beschermt.

Wat veroorzaakt de certificaatfout in de webinterface van CipherTrust Manager?

De fout wordt veroorzaakt door een mislukte TLS-vertrouwenscontrole van uw browser, niet door een storing in CipherTrust Manager. Elk CipherTrust Manager-knooppunt wordt geleverd met een certificaat voor de webinterface. Standaard wordt dit certificaat automatisch gegenereerd en ondertekend door de lokale CA van het apparaat (meestal aangeduid als de KeySecure Root CA in de interface). Browsers vertrouwen deze lokale CA niet standaard, waardoor bij de allereerste aanmelding bij een nieuw knooppunt doorgaans een certificaatwaarschuwing verschijnt, ook al is er niets mis. Dezelfde waarschuwing verschijnt om een ​​andere reden wanneer een organisatie het standaardcertificaat vervangt door een certificaat van een externe of bedrijfs-CA: als de upload onvolledig, verkeerd geconfigureerd, verlopen of uitgegeven is voor de verkeerde hostnaam, wordt deze door de browser geweigerd om een ​​specifieke, traceerbare reden.

Veelvoorkomende oorzaken van de certificaatfout in de webinterface van CipherTrust Manager

De meeste gevallen worden door vier oorzaken verklaard. Elke oorzaak komt overeen met een aparte foutcode van de browser, wat de snelste manier is om ze van elkaar te onderscheiden voordat u begint met het oplossen van problemen.

Niet-vertrouwde of zelfondertekende CA (NET::ERR_CERT_AUTHORITY_INVALID)

Het certificaat is geldig en niet verlopen, maar de browser of het besturingssysteem vertrouwt de certificeringsinstantie (CA) die het heeft ondertekend niet. Dit is de standaardstatus voor een nieuw CipherTrust Manager-knooppunt en treedt ook op als het root- of tussenliggende certificaat van een externe CA nooit is toegevoegd aan de lijst met externe vertrouwde CA's van de interface.

Verlopen of nog niet geldig certificaat (NET::ERR_CERT_DATE_INVALID)

Dit kan op twee manieren gebeuren: het certificaat is daadwerkelijk verlopen zonder te worden verlengd, of de systeemklok van het CipherTrust Manager-knooppunt is niet meer gesynchroniseerd met NTP. De eigen certificaatuitgiftelogica van Thales past de datum in het veld 'notBefore' ongeveer 24 uur aan om kleine tijdzone- en klokverschillen tussen knooppunten op te vangen. Daardoor wijzen hardnekkige datumfouten bijna altijd op een NTP-probleem en niet op het certificaat zelf.

Hostnaam komt niet overeen (NET::ERR_CERT_COMMON_NAME_INVALID)

De Common Name (algemene naam) of Subject Alternative Name (SAN) van het certificaat komt niet overeen met de hostnaam of het IP-adres dat in de browser is ingevoerd. Dit komt vaak voor nadat een node is hernoemd, een nieuw IP-adres heeft gekregen of aan een cluster is toegevoegd, of wanneer een certificaat is aangevraagd voor een load-balanced hostnaam waarmee individuele nodes ook rechtstreeks worden benaderd.

Certificaat geüpload, maar nog niet actief

Direct na het uploaden van een nieuw certificaat en het herstarten van de webservice kan de browser nog enkele minuten de oude waarschuwing weergeven. Onze engineers hebben gemerkt dat dit vrijwel altijd te wijten is aan de certificaatcache van de browser zelf of aan het feit dat de herstart van de service nog niet voltooid is, en niet aan een inherente vertraging in CipherTrust Manager zelf, aangezien de documentatie van Thales aangeeft dat nieuw uitgegeven certificaten direct actief zijn. Een harde vernieuwing van de pagina of het openen van een privévenster na de herstart lost het probleem meestal op.

Hoe los ik de certificaatfout in de webinterface van CipherTrust Manager op?

De onderstaande stappen vervangen het standaardcertificaat, dat niet door de browser wordt vertrouwd, door een certificaat dat is ondertekend door een externe of bedrijfs-CA. Dit voorbeeld configureert een certificaat voor een node met de naam thales01.ec.com; vervang dit door uw eigen hostnaam.

1. Log in bij CipherTrust Manager. Klik vanuit het dashboard op CSR Tool onder CA.

   

2. Klik op + CSR aanmaken en voer de vereiste informatie in, inclusief een algemene naam die exact overeenkomt met de hostnaam (en alternatieve onderwerpnamen voor eventuele extra DNS-namen of IP-adressen) die u zult gebruiken om dit knooppunt te bereiken.

   

3. Controleer de gegevens en klik op 'Aanmaken'.

4. Bewaar de privésleutel en de CSR. Voor de hoogste mate van beveiliging raadt Thales aan de CSR volledig buiten CipherTrust Manager te genereren, zodat de privésleutel nooit aan het apparaat wordt blootgesteld; de ingebouwde CSR-tool is voor de meeste implementaties de eenvoudigere optie.

   

5. Stuur de CSR naar uw bevoegde instantie om het ondertekende certificaat te laten maken.

   Opmerking: Het voorkeurscertificaatformaat is PEM. PKCS12 wordt ook ondersteund voor de gecombineerde certificaatketen en privésleutel.

6. Upload de root- en intermediaire CA-certificaten. Klik in het dashboard op 'Extern' onder het gedeelte 'CA'.

   

7. Klik op + Externe CA toevoegen.

   

8. Voer een weergavenaam in en plak het root-CA-certificaat in het vak. Klik vervolgens op Opslaan.

   

9. Herhaal dezelfde stappen om de tussenliggende of uitgevende CA toe te voegen.

10. Ga naar Interfaces onder Beheerinstellingen.

    

11. Klik op het menu met de drie puntjes naast Web en selecteer Bewerken.

    

12. Schakel onder 'Automatische generatie van servercertificaten' de automatische generatie vanuit de lokale CA uit. Deze stap is belangrijker dan het lijkt: als u deze overslaat, kan CipherTrust Manager de volgende keer dat de webservice opnieuw wordt opgestart een zelfondertekend certificaat genereren en de rest van dit proces ongemerkt ongedaan maken.

    

13. Voeg de root-CA en de intermediaire CA toe aan de lijst met externe vertrouwde CA's voor deze interface.

    

14. Vouw de optie 'Certificaat uploaden' uit en plak de volledige certificaatketen (bladcertificaat, gevolgd door tussenliggend certificaat en rootcertificaat) in het vak.
15. Selecteer PEM als formaat.
16. Voer het wachtwoord van de privésleutel in, indien dit tijdens het genereren van de CSR is ingesteld.
17. Klik op 'Nieuw certificaat uploaden'. Het extern ondertekende certificaat is nu toegewezen aan de webinterface.
18. Ga naar Services onder Beheerinstellingen.

19. Klik op Systeem opnieuw opstarten om de wijziging toe te passen.

    

20. Zodra de services opnieuw zijn opgestart, ga dan naar de hostnaam van CipherTrust Manager. Als er nog steeds een certificaatfout optreedt, wacht dan een paar minuten totdat de herstart volledig is voltooid en de certificaatcache van de client is gewist. Vernieuw vervolgens de pagina voordat u verdergaat met het oplossen van het probleem.

Bij een geclusterde CipherTrust Manager-implementatie herhaalt u dit proces op elk knooppunt afzonderlijk. Interfacecertificaten worden per knooppunt geconfigureerd en niet automatisch over het cluster gerepliceerd, net zoals back-upsleutels niet automatisch tussen knooppunten worden gedeeld, zoals beschreven in onze handleiding voor back-upfouten van CipherTrust Manager.

Beslissingstabel: Symptoom, oorzaak en oplossing

Symptoom	waarschijnlijke oorzaak	Bepalen
NET::ERR_CERT_AUTHORITY_INVALID of “niet vertrouwd” waarschuwing	Certificaat ondertekend door de standaard lokale CA, of de externe CA-keten is nooit toegevoegd aan de externe vertrouwde CA's.	Voeg de root- en intermediaire CA toe aan de externe vertrouwde CA's, of vervang het standaardcertificaat door een extern ondertekend certificaat.
NET :: ERR_CERT_DATE_INVALID	Het certificaat is daadwerkelijk verlopen, of de klok van het CipherTrust Manager-knooppunt loopt niet meer gelijk met NTP.	Controleer de geldigheidsdatum van het certificaat in de interface; corrigeer eerst de NTP-synchronisatie en vernieuw het certificaat alleen als het daadwerkelijk is verlopen.
NET :: ERR_CERT_COMMON_NAME_INVALID	De CN of SAN van het certificaat komt niet overeen met de hostnaam of het IP-adres waarmee de interface is bereikt.	Vernieuw het certificaat met de correcte CN- en SAN-gegevens voor elke hostnaam en elk IP-adres waarmee het knooppunt wordt benaderd.
De waarschuwing verschijnt opnieuw direct na een succesvolle upload en herstart.	Automatische generatie van certificaten van de lokale CA was ingeschakeld gebleven en werd bij het herstarten opnieuw geactiveerd, of de browser had het oude certificaat in de cache opgeslagen.	Schakel het automatisch genereren van servercertificaten uit voordat u gaat uploaden; start de service opnieuw; wis de certificaatcache van uw browser of gebruik een privévenster.
De foutmelding is identiek op elk knooppunt in een cluster.	Het certificaat is slechts naar één knooppunt geüpload; interfacecertificaten worden niet over het cluster gerepliceerd.	Herhaal de stappen voor het genereren en uploaden van de CSR afzonderlijk op elk knooppunt.

Levenscyclusbeheer van het certificaat voor de webinterface

Omdat CipherTrust Manager het controlepaneel is voor encryptiesleutels, verdient het certificaat voor de webinterface dezelfde eigendomsstructuur als een certificaat dat een geprivilegieerde beheerdersconsole beschermt. In de praktijk betekent dit dat een specifiek team, meestal de groep voor sleutelbeheer of PKI-operaties in plaats van een algemene IT-helpdesk, wordt aangewezen als eigenaar van dit certificaat op elke node en in elk cluster van de organisatie. Deze eigenaar is verantwoordelijk voor het bijhouden van de uitgever, de vervaldatum en de hostnaamdekking van het certificaat; het verlengen ervan vóór de vervaldatum in plaats van te reageren op een browserwaarschuwing; en het bewaren van de CSR, het ondertekende certificaat en de CA-keten op dezelfde locatie met wijzigingsbeheer als ander productiemateriaal voor TLS. Het behandelen van dit certificaat als een niet-beheerd, eenmalig ingesteld artefact is precies de reden waarom organisaties het uiteindelijk opnieuw ontdekken via een geblokkeerde beheerdersconsole.

Rotatietriggers voor dit certificaat

CipherTrust Manager zelf registreert vervalwaarschuwingen 91, 7 en 0 dagen voordat een certificaat verloopt, wat een redelijke basislijn is voor een rotatiekalender. Naast de reguliere vervaldatum is het raadzaam om het certificaat van de webinterface te roteren wanneer een van de volgende situaties zich voordoet:

• Het certificaat nadert een van de vervaldrempels van 91, 7 of 0 dagen die CipherTrust Manager intern bijhoudt.
• De uitgevende certificeringsinstantie is gecompromitteerd, wordt door browservertrouwensarchieven als verouderd beschouwd of wordt buiten gebruik gesteld als onderdeel van een PKI-migratie.
• Een node wordt hernoemd, krijgt een nieuw IP-adres of wordt toegevoegd achter een nieuwe load-balanced hostnaam, waardoor de CN of SAN die het certificaat moet dekken, verandert.
• De organisatie stapt over van het standaard zelfondertekende certificaat naar een certificaat dat extern of intern is uitgegeven door een certificeringsinstantie (CA).
• Er bestaat een vermoeden dat een beheerdersaccount met toegang tot de secties Interfaces of CA is gecompromitteerd, aangezien die toegang voldoende is om dit certificaat te vervangen.
• Een geplande audit of penetratietest wijst uit dat de sleutellengte, het ondertekeningsalgoritme of de geldigheidsperiode van het certificaat niet aan het beleid voldoet.

Toegangsbeleid: Wie mag dit certificaat vervangen?

Het uploaden van een nieuw certificaat naar de webinterface, het toevoegen van een vermelding aan Externe Vertrouwde CA's en het herstarten van de webservice zijn allemaal administratieve acties die worden uitgevoerd onder Beheerinstellingen. Dit betekent dat degene met die toegang in zijn eentje kan wijzigen welke certificaten elke browser vertrouwt bij het verbinden met de sleutelbeheerconsole. Deze bevoegdheid zou moeten worden toevertrouwd aan een kleine, specifieke groep, doorgaans de systeembeheerders van CipherTrust Manager of een specifieke PKI-beheerder, in plaats van aan de brede groep gebruikers met algemene beheerdersrechten op het apparaat. Scheid de mogelijkheid om een ​​certificaatwijziging aan te vragen en goed te keuren van de mogelijkheid om deze uit te voeren, waar het wijzigingsbeheerproces van de organisatie dit toelaat, en vereis een gedocumenteerd wijzigingsticket voor elke wijziging van Interfaces of Externe Vertrouwde CA's, zelfs voor routinematige verlengingen.

Controlebewijs voor certificaatwijzigingen

Elke certificaatvervanging via de webinterface moet een spoor achterlaten dat een auditor kan volgen zonder dat een beheerder hoeft te onthouden wat er is gebeurd. Bewaar minimaal de originele CSR, het ondertekende certificaat en de bijbehorende CA-keten, het wijzigingsticket of de goedkeuringsrecord die de update autoriseert, en een tijdstempel van het moment waarop de service opnieuw is opgestart om de wijziging toe te passen. Vergelijk deze gegevens met de logboekregistratie van CipherTrust Manager, waarin configuratiewijzigingen via de interface worden vastgelegd. Zo komt een onverklaarde certificaatwijziging aan het licht tijdens een routinematige logboekcontrole in plaats van tijdens een incidentmelding. Voor organisaties die certificaten op deze schaal beheren over meerdere apparaten, biedt een gecentraliseerd certificaatlevenscyclusplatform dat de uitgifte, verlenging en implementatie automatisch van een tijdstempel voorziet, dit bewijsmateriaal zonder dat handmatige documentatie nodig is.

Handmatige certificaatvervanging versus geautomatiseerd certificaatlevenscyclusbeheer

De bovenstaande stappen beschrijven een handmatig proces, en voor één CipherTrust Manager-node is dit beheersbaar. Het wordt echter onbeheersbaar zodra een organisatie een cluster met meerdere nodes, meerdere omgevingen of tientallen apparaten in verschillende regio's beheert, omdat elk certificaat afzonderlijk moet worden bijgehouden, vernieuwd en gecontroleerd, zonder dat er sprake is van gedeeld inzicht tussen de nodes.

Overweging	Handmatige vervanging	Geautomatiseerd beheer van de levenscyclus van certificaten
Vervaldatum bijhouden	Vertrouwt erop dat de 91/7/0-dagen logboekwaarschuwingen van CipherTrust Manager zelf worden opgemerkt en verwerkt per node.	Continue monitoring en proactieve vernieuwing op elk knooppunt vóór de vervaldatum.
Inspanning op grote schaal	Lineair met het aantal knooppunten; elk knooppunt vereist een eigen CSR, upload en herstart.	Gecentraliseerde uitgifte en inzet binnen een vloot, met een consistente toepassing van het beleid.
Controlespoor	Handmatige registratie buiten het apparaat, waardoor je gemakkelijk achterop raakt.	Automatische, van tijdstempels voorziene registratie van uitgifte, verlenging en implementatie.
Risico op menselijke fouten	Hoger; een overgeslagen stap (zoals het ingeschakeld laten van automatische generatie) kan de correctie ongemerkt ongedaan maken.	Lager; de workflow zorgt ervoor dat de juiste volgorde elke keer wordt afgedwongen.
Beste pasvorm	Een enkele node of een kleine, statische implementatie	Geclusterde, multiregionale of groeiende CipherTrust Manager-implementaties

Incidentrespons: onschuldige afloop of daadwerkelijke inbreuk?

De meeste certificaatwaarschuwingen op deze interface zijn onschuldig: een verlopen certificaat dat niemand in de gaten hield, een knooppunt dat nooit een vertrouwd certificaat heeft gekregen, of NTP-afwijking. Behandel de fout anders en escaleer deze als een van de volgende situaties zich voordoet:

• Het certificaat is onverwacht gewijzigd, zonder dat er een bijbehorende wijzigingsaanvraag of onderhoudsperiode geregistreerd stond.
• Het certificaat is ondertekend door een certificeringsinstantie die door niemand wordt erkend als een goedgekeurde uitgever voor deze omgeving.
• Het logboek met beheerdersactiviteiten toont een wijziging in interfaces of externe vertrouwde CA's, uitgevoerd door een account dat daar geen toegang toe zou mogen hebben, of op een moment dat er niemand aan het werk was.
• Gebruikers melden dat de waarschuwing af en toe verschijnt in plaats van constant, wat erop kan duiden dat het verkeer wordt onderschept door een ongeautoriseerd certificaat in plaats van een eenvoudig configuratieprobleem.

Als een van deze situaties van toepassing is, klik dan niet zomaar door de waarschuwing heen of geef geen vervangend certificaat uit en ga verder. Raadpleeg het logboek met beheerdersactiviteiten voor het betreffende knooppunt, achterhaal wie de wijziging heeft aangebracht en vanaf welke locatie, wijzig de inloggegevens voor alle accounts met interfaces of CA-toegang en beschouw de CipherTrust Manager-console zelf als een systeem dat mogelijk het doelwit is geweest, aangezien deze zich voor het encryptiesleutelmateriaal van de organisatie bevindt. Pas nadat dit onderzoek is afgerond, mag het certificaat opnieuw worden uitgegeven en het incident worden gedocumenteerd samen met het hierboven beschreven auditbewijs.

Beperkingen

Deze handleiding beschrijft het TLS-certificaat dat de toegang van browsers tot de webinterface van CipherTrust Manager beveiligt. Het behandelt niet de certificaatgebaseerde gebruikersauthenticatie voor die interface, certificaten die CipherTrust Manager uitgeeft of beheert namens andere systemen via zijn eigen CA-services, of de afzonderlijke KMIP- en NAE-XML-interfaces, die onafhankelijk van elkaar worden geconfigureerd in hetzelfde gedeelte Interfaces. Menulabels en klikpaden kunnen enigszins variëren tussen CipherTrust Manager-releases; controleer de exacte stappen in de officiële documentatie van Thales voor uw specifieke versie voordat u wijzigingen aanbrengt in een productieomgeving.

Wat zou Encryption Consulting aanbevelen?

We zouden het certificaat van de webinterface niet handmatig beheren, zeker niet wanneer een organisatie meer dan één CipherTrust Manager-node gebruikt. Ons CertSecure Manager- platform biedt teams voor certificaatlevenscyclusbeheer een gecentraliseerde manier om certificaten voor dit type administratieve interfacecertificaten te ontdekken, te vernieuwen en te controleren. Hierdoor wordt het verlopen van een certificaat een geplande gebeurtenis in plaats van een browserwaarschuwing waar gebruikers per ongeluk tegenaan lopen. Voor organisaties die nog geen interne CA hebben die vertrouwde certificaten kan uitgeven aan apparaten zoals CipherTrust Manager, biedt onze PKI-as-a-Service -oplossing die mogelijkheid zonder de overhead van een eigen CA. En als uw team problemen ondervindt met een CipherTrust Manager-implementatie die verder gaan dan deze specifieke fout, bieden onze CipherTrust Manager-ondersteuningsservices praktische Thales-expertise voor configuratie-, migratie- en clusteringproblemen.

Conclusie

De certificaatfout in de webinterface van CipherTrust Manager wordt bijna altijd veroorzaakt door een van de volgende vier dingen: een niet-vertrouwde CA, een verlopen of nog niet geldig certificaat, een onjuiste hostnaam of een verouderde browsercache na een legitieme wijziging. De oplossing is eenvoudig zodra je weet welke oorzaak het betreft. Wat een robuuste implementatie onderscheidt van een implementatie die deze fout volgend jaar opnieuw zal vertonen, is het behandelen van het certificaat zelf als een beheerd onderdeel, met een benoemde eigenaar, een rotatieschema gekoppeld aan de vervalwaarschuwingen van CipherTrust Manager, beperkte toegang om het te wijzigen en een auditlogboek dat elke wijziging achteraf verklaart.

FAQ

Wat betekent NET::ERR_CERT_AUTHORITY_INVALID in de webinterface van CipherTrust Manager?
Dit betekent dat de browser de certificeringsinstantie (CA) die het door de interface gepresenteerde certificaat heeft ondertekend, niet kon verifiëren. Dit is te verwachten bij de eerste keer dat u een nieuw CipherTrust Manager-knooppunt benadert, aangezien dit knooppunt wordt geleverd met een zelfondertekend certificaat van de lokale CA. Het probleem kan ook optreden na het installeren van een extern ondertekend certificaat als de root- en tussenliggende certificaten van die CA nooit zijn toegevoegd aan de externe vertrouwde CA's.

Waarom gebruikt CipherTrust Manager standaard een zelfondertekend certificaat?
Het apparaat heeft een werkend HTTPS-certificaat nodig voordat een beheerder de interface kan bereiken om andere instellingen te configureren. Daarom genereert het apparaat automatisch een certificaat van zijn eigen lokale certificeringsinstantie (CA) tijdens de initialisatie. Dit certificaat is functioneel, maar wordt niet vertrouwd door externe browsers of besturingssystemen totdat het wordt vervangen door een certificaat dat is ondertekend door een CA die uw omgeving al vertrouwt.

Hoe vaak moet het certificaat van de CipherTrust Manager-webinterface worden vernieuwd?
Vervang het certificaat voordat de vervaldrempels van 91, 7 en 0 dagen, zoals intern geregistreerd door CipherTrust Manager, worden bereikt. Beschouw elke organisatorische trigger, zoals een vermoedelijke inbreuk op inloggegevens, een wijziging van de hostnaam of het buiten gebruik stellen van een CA, als een onmiddellijke vervangingsgebeurtenis, ongeacht in welke fase van de geldigheidsperiode het certificaat zich bevindt.

Kan ik een openbaar erkend CA-certificaat gebruiken voor de beheerdersinterface van CipherTrust Manager?
Ja, zolang de hostnaam van CipherTrust Manager oplosbaar is en de CA deze kan valideren. De meeste organisaties geven dit certificaat echter uit via een interne bedrijfs- of privé-CA, omdat de beheerinterface doorgaans beperkt is tot interne netwerken en geen validatie door een openbare CA vereist.

Wordt een certificaat dat naar één node wordt geüpload, toegepast op het gehele CipherTrust Manager-cluster?
Nee. Webinterfacecertificaten worden per node geconfigureerd en worden niet automatisch gerepliceerd over een cluster, net zoals back-upsleutels op elke node afzonderlijk moeten worden beheerd. Elke node heeft een eigen CSR, ondertekend certificaat en upload via de beheerdersinstellingen nodig.

Referenties

• Thales-documentatie: CipherTrust Manager-certificaatautoriteit
• Thales-documentatie: CipherTrust Manager-interfaces
• Thales-documentatie: Certificaatgebaseerde authenticatie
• Thales: Overzicht van CipherTrust Manager