Snel antwoord: Om een certificaat op Apache Tomcat te vernieuwen met CertSecure Manager, genereert of hergebruikt u een CSR vanuit de inschrijvingsconsole van CertSecure Manager, vraagt u het certificaat aan bij de verbonden certificeringsinstantie, downloadt u het ondertekende PFX-bestand en vervangt u het keystore-bestand waarnaar wordt verwezen in de betreffende code. server.xmlen herstart Tomcat zodat het vernieuwde certificaat wordt geladen.

Een Apache Tomcat-certificaat dat onverwacht verloopt, kan een productieapplicatie binnen enkele minuten offline halen. Verlopen certificaten zijn een van de meest voorkomende oorzaken van ongeplande storingen in bedrijfsomgevingen. Dit artikel laat zien hoe u een certificaat op een website die op Apache Tomcat draait, kunt vernieuwen door het certificaat aan te vragen bij CertSecure Manager . Het beschrijft ook de handmatige stappen die op de server nodig zijn om de vernieuwing te voltooien.

Key Takeaways

Het vernieuwen van een Tomcat-certificaat via CertSecure Manager resulteert nog steeds in een handmatige keystore-wissel en herstart, tenzij er een Renewal Agent op de server is geïmplementeerd.
CertSecure Manager kan de CSR genereren, deze naar de aangesloten CA verzenden en een direct inzetbaar PFX-bestand produceren, waardoor de meeste handmatige stappen voor interactie met de CA overbodig worden.
Uit een onderzoek van DigiCert, gepubliceerd op 2 juli 2025, bleek dat 45% van de organisaties te maken had met uitval als gevolg van certificaatproblemen, en dat 37.5% dit direct kon herleiden tot verlopen certificaten.
De geldigheidsduur van openbare TLS-certificaten neemt af volgens een vast schema van de CA/B Forum: 200 dagen vanaf maart 2026, 100 dagen vanaf maart 2027 en 47 dagen vanaf maart 2029. Hierdoor zullen handmatige verlengingen van Tomcat-certificaten veel vaker nodig zijn.
Teams die de verlenging automatiseren met Renewal Agents, elimineren de terugkerende handmatige stap die in dit artikel wordt beschreven volledig.

Voorwaarden

Controleer het volgende voordat u de verlenging start:

Toegang tot CertSecure Manager: een account met inschrijfrechten en een certificeringsinstantie die al via een CA Connector is verbonden.
Servertoegang: Beheerdersrechten of sudo-rechten voor de Apache Tomcat-host, en het bestandspad naar de bestaande keystore.
Huidige beschikbare configuratie: het bestaan server.xml connectorblok, huidig keystore-pad en keystore-wachtwoord (of een plan om het te wijzigen).
Back-up: een kopie van het huidige keystore-bestand en server.xml Foto genomen voordat de wijzigingen werden aangebracht.
Onderhoudsvenster: Tomcat moet opnieuw opstarten om het nieuwe certificaat te laden, dus houd rekening met een korte serviceonderbreking of een load-balanced failover.
SAN- en sjabloongegevens: Controleer of de Subject Alternative Names, de sleutelgrootte en de certificaatsjabloon van het vernieuwde certificaat overeenkomen met het originele certificaat.

Wat is CertSecure Manager?

CertSecure Manager van Encryption Consulting is een oplossing voor certificaatlevenscyclusbeheer (CLM) die is ontwikkeld om de uitdagingen aan te pakken waarmee organisaties te maken krijgen bij het beheren van complexe PKI- omgevingen. Naarmate het aantal digitale certificaten in een omgeving toeneemt, wordt het handmatig bijhouden van vervaldatums en verlengingsperioden onbetrouwbaar. De High-Availability (HA)-architectuur van CertSecure Manager integreert openbare en private certificeringsinstanties op één platform, ongeacht of de omgeving multi-cloud, hybride of een mix van openbare en private CA's is.

Met Renewal Agents kan CertSecure Manager certificaatvernieuwingen automatiseren, rechtstreeks op IIS, Tomcat en F5 load balancers, zodat certificaten actueel blijven zonder de handmatige stappen die in dit artikel worden beschreven. De certificaatdetectiefunctie houdt elk certificaat bij dat in een omgeving is geïmplementeerd, ongeacht waar het is uitgegeven of geïnstalleerd, en de ondersteuning voor ACME en REST API stelt applicatieteams in staat om certificaten programmatisch aan te vragen en te vernieuwen.

Stapsgewijze handleiding voor het verlengen van een certificaat op Apache Tomcat

Er zijn twee manieren om een certificaat voor Apache Tomcat te verkrijgen via CertSecure Manager: een CSR rechtstreeks in het platform genereren of een certificaat aanvragen op basis van een bestaande CSR. Beide methoden elimineren de meeste handmatige stappen die normaal gesproken nodig zijn om een certificaat van een certificeringsinstantie (CA) te verkrijgen.

Volg deze stappen om een certificaat van CertSecure Manager te vernieuwen en te implementeren op Apache Tomcat.

Open 'Certificaat genereren' in CertSecure Manager: Log in bij CertSecure Manager en ga naar 'Certificaat genereren' onder het gedeelte 'Inschrijving' aan de linkerkant. Deze procedure genereert het certificaat en downloadt een PFX-bestand rechtstreeks vanuit CertSecure Manager, waardoor een aparte keystore of openssl-stap niet nodig is.
Selecteer de CA-, sjabloon- en SAN-kenmerken: Kies de certificeringsinstantie, de certificaatsjabloon, de Subject Alternative Name (SAN)-gegevens en eventuele andere vereiste velden en klik vervolgens op Certificaat genereren.

Een certificaat genereren voor Apache Tomcat vanuit de CertSecure Manager-inschrijvingsconsole.
Zoek en download het certificaat: Ga naar de inschrijvingsinventaris en zoek het nieuwe certificaat (controleer de takenweergave als u de inschrijvings-ID nodig hebt). Download het PFX-bestand en verplaats het vervolgens naar de Apache Tomcat-server.
Vervang de keystore en werk server.xml indien nodig bij: Plaats het PFX-bestand op de locatie waar het huidige certificaat en de sleutel zijn opgeslagen. Als het pad of het wachtwoord wijzigt, moet u het pad en het wachtwoord van de keystore bijwerken. server.xmlAls uw Tomcat-server bijvoorbeeld het PFX-bestand op de C:-schijf bewaart, plaatst u het nieuwe bestand op hetzelfde pad of werkt u het pad bij. keystoreFile en keystorePass waarden om naar het nieuwe bestand te verwijzen.
Tomcat opnieuw starten: Start de Tomcat-service opnieuw zodat het vernieuwde certificaat wordt geladen. Controleer de nieuwe vervaldatum in de browser of met een SSL-controletool voordat u de wijziging opslaat.

Voorbeeld: server.xml Keystore-configuratie

Een typische Tomcat HTTPS-connector die verwijst naar een PFX-sleutelarchief ziet er als volgt uit. Update keystoreFile en keystorePass om naar het vernieuwde certificaat te wijzen:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" SSLEnabled="true">
    <SSLHostConfig>
        <Certificate certificateKeystoreFile="conf/renewed-cert.pfx"
                     certificateKeystorePassword="CHANGE_ME"
                     certificateKeystoreType="PKCS12" />
    </SSLHostConfig>
</Connector>

Voor en na: Handmatige versus geautomatiseerde verlengingsworkflow

Stap voor	Handmatige verlenging (deze handleiding)	Geautomatiseerd met een verlengingsagent
MVO en inschrijving	Gegenereerd in CertSecure Manager, handmatig ingediend	Wordt automatisch geactiveerd vóór de vervaldatum.
Certificaat ophalen	Handmatig gedownload uit de inschrijvingslijst.	Direct door de agent naar de server verzonden.
Keystore vervanging	Handmatig gekopieerd en, indien nodig, bewerkt: server.xml	Wordt automatisch afgehandeld door de agent.
Service opnieuw opstarten	Handmatig geactiveerd, vereist een onderhoudsvenster.	Beheerd door de agent, minimale of geen downtime.
Controlespoor	Afhankelijk van handmatig ingevoerde wijzigingsregistraties	Automatisch ingelogd bij CertSecure Manager
Risico op gemiste verlenging	Hoger, afhankelijk van of iemand de vervaldatum in de gaten houdt.	Laag, verlenging gepland vóór vervaldatum

Eigenaar- en actiematrix

Het verlengen van certificaten voor Tomcat raakt meerdere teams. Gebruik deze matrix om de bovenstaande voorbereidende werkzaamheden aan de juiste persoon toe te wijzen.

Voorwaarde / taak	Eigendomsteam	Actie
CA Connector en inschrijvingsrechten	PKI-team	Controleer of CertSecure Manager is verbonden met de juiste CA en of de aanvrager inschrijvingsrechten heeft.
SAN-, sjabloon- en sleutelgroottevalidatie	Beveiligingsteam	Keur het certificaatsjabloon goed en bevestig dat het voldoet aan het huidige beleid.
Venster voor servertoegang, back-up en herstart	Platform-/infrastructuurteam	Maak een back-up van de keystore en server.xml en plan het herstartvenster in.
Controleverslag en bewijs van verlenging	Complianceteam	Bevestig dat de verlenging is geregistreerd en bewaard voor de volgende auditcyclus.
Rollback-gereedheid	Platform-/infrastructuurteam	Controleer of de vorige sleutelopslag herstelbaar is voordat u begint.

Richtlijnen voor terugdraaien

Als het vernieuwde certificaat niet laadt of de verbinding verbreekt, ga dan terug naar de vorige versie voordat u verdergaat met het oplossen van het probleem:

Stop de Tomcat-service.
Herstel het back-upbestand van de keystore en het origineel. server.xml connectorblok.
Herstart Tomcat en controleer of de site het vorige, nog steeds geldige certificaat gebruikt.
Controleer het SAN-nummer, de sjabloon en het wachtwoord van de keystore die bij de mislukte poging zijn gebruikt voordat u de verlenging opnieuw probeert.
Als het oorspronkelijke certificaat bijna verloopt, probeer het dan opnieuw te verlengen tijdens een onderhoudsperiode in plaats van de terugdraaiing permanent te laten staan.

Veelvoorkomende fouten en probleemoplossing

Symptoom	waarschijnlijke oorzaak	Bepalen
Tomcat start niet meer op na herstart.	Onjuist pad naar de keystore of onjuist wachtwoord in server.xml	Controleer of certificateKeystoreFile en certificateKeystorePassword overeenkomen met het nieuwe PFX-bestand.
De browser toont nog steeds het oude certificaat.	Load balancer of CDN die het vorige certificaat in de cache opslaat.	Wis de cache of update het certificaat op het load balancer/CDN-niveau.
Waarschuwing voor SAN-mismatch	Het nieuwe certificaatsjabloon heeft niet alle oorspronkelijke SAN-gegevens overgenomen.	Genereer de CSR opnieuw in CertSecure Manager met de volledige, actuele SAN-lijst.
Aanmelding blijft hangen in CertSecure Manager-taken.	Goedkeuring van de CA Connector in afwachting of validatie aan de CA-zijde vertraagd.	Controleer de status van de CA Connector en de openstaande goedkeuringen in CertSecure Manager.
PFX-import mislukt	Onjuist type keystore opgegeven in server.xml	Controleer of certificateKeystoreType is ingesteld op PKCS12 voor een PFX-bestand.

Successtatistieken om bij te houden

Nadat u deze workflow hebt geïmplementeerd, kunt u de volgende statistieken bijhouden om te bevestigen dat het verlengingsproces werkt en om de overstap naar verlengingsagenten te onderbouwen:

Gemiddelde verlengingstermijn: De tijd die verstrijkt tussen het genereren van het CSR-certificaat en het moment dat een geldig, vernieuwd certificaat op de server staat.
Certificaten die op tijd zijn verlengd versus certificaten die onverwacht zijn verlopen: Het aantal verlengingen dat vóór de vervaldatum is voltooid, versus noodreparaties na de vervaldatum.
Handmatige tickets gekoppeld aan certificaatvernieuwing: aantal helpdesk- of wijzigingstickets dat per kwartaal is geopend voor werkzaamheden met betrekking tot Tomcat-certificaten.
Certificaten beheerd door CertSecure Manager: Het totale aantal Tomcat-certificaten (en andere certificaten) dat wordt bijgehouden in de ontdekkingsinventaris van het platform.
Ongeplande uitvalincidenten gerelateerd aan certificaten: Dit werd vergeleken met de branchenorm, waaruit bleek dat in een onderzoek van DigiCert, gepubliceerd op 2 juli 2025, 45% van de organisaties melding maakte van downtime als gevolg van certificaatproblemen.

Encryption Consulting heeft op het moment van deze update geen certificaatspecifieke, kwartaalgebonden benchmark (bijvoorbeeld bespaarde verlengingstijd of vermindering van het aantal tickets) gepubliceerd voor CertSecure Manager-implementaties. Als uw team interne cijfers heeft van vóór en na een CertSecure Manager-uitrol, voeg deze dan hier toe met het kwartaal waarin ze zijn gemeten, in plaats van alleen te vertrouwen op indicatieve beweringen.

Waarom handmatige certificaatvernieuwing het bedrijfsrisico verhoogt

Handmatige verlenging, zoals de bovenstaande stappen, werkt, maar het is afhankelijk van iemand die de vervaldatum onthoudt, op het juiste moment de juiste toegang heeft en elke stap correct uitvoert onder tijdsdruk. Die afhankelijkheid is de oorzaak van storingen. Uit een DigiCert Trust Pulse-enquête die op 2 juli 2025 werd gepubliceerd, bleek dat 45% van de organisaties te maken had met downtime als gevolg van certificaten, en dat 37.5% van die storingen direct verband hield met verlopen certificaten.

Het risicovenster wordt ook korter. Volgens CA/B Forum Ballot SC-081v3 , aangekondigd door Sectigo op 14 april 2025, daalt de maximale geldigheidsduur van openbare TLS-certificaten naar 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029. Een handmatig vernieuwingsproces per Tomcat, dat beheersbaar is met een frequentie van 398 dagen of een jaar, wordt een terugkerende operationele last bij een frequentie van 47 dagen. Dit is precies de reden waarom certificaatautomatisering en certificaatdetectie steeds belangrijker worden in elke fase van dit schema.

Overwegingen bij multi-cloud en hybride PKI

Tomcat-instanties draaien zelden geïsoleerd. In bedrijfsomgevingen draait Tomcat vaak achter loadbalancers in de cloud, naast on-premises Active Directory Cloud Storage (AD CS) en met meerdere openbare certificeringsinstanties (CA's). De HA-architectuur en CA-connectoren van CertSecure Manager zijn ontworpen voor deze realiteit: certificaten uitgegeven door meerdere openbare en private CA's zijn zichtbaar en beheersbaar vanuit één console, en certificaatdetectie vindt Tomcat en andere certificaten die zijn geïmplementeerd in cloud-, hybride en on-premises infrastructuren, zodat een verlenging niet afhankelijk is van het kennen van elke server bij naam. Voor teams die certificaten beheren in meerdere clouds, biedt de combinatie van certificaatdetectie met CBOM Secure dezelfde zichtbaarheid voor de bredere cryptografische inventaris, niet alleen voor TLS-certificaten.

Hoe dit verband houdt met PQC-gereedheid en crypto-flexibiliteit

Naast het oplossen van dit ene certificaatprobleem raden we het volgende aan: beschouw elke handmatige verlenging van Tomcat als een signaal, niet als een eenmalige taak. Elk certificaat waarvoor nog steeds een mens een CSR moet genereren, een PFX moet downloaden en een service opnieuw moet opstarten, is een certificaat waarvoor uw organisatie nog geen cryptografische flexibiliteit heeft. Die lacune is niet alleen belangrijk voor TLS. Zoals het PQC Center of Excellence -team herhaaldelijk ziet, zullen organisaties die hun certificaten vandaag de dag niet snel kunnen inventariseren en vernieuwen, moeite hebben met een post-quantummigratie wanneer die nodig is. PQC-gereedheid begint met dezelfde certificaatdetectie en automatisering van de levenscyclus waar de handmatige stappen in dit artikel op gebaseerd zijn.

Als u dit Tomcat-certificaat in een bredere cryptografische inventaris wilt opnemen, legt de CBOM- aanpak voor het omzetten van inventaris naar intelligentie uit hoe u van een statische lijst met certificaten overgaat naar iets waar een beveiligings- of compliance-team daadwerkelijk actie op kan ondernemen.

Wat te doen vervolgens? (door Team)

PKI-teams

Controleer of de CA Connector en template van elke Tomcat-instantie actueel zijn voordat de volgende mijlpaal in het 47-dagenplan ingaat.
Identificeer welke Tomcat-servers nog handmatig worden verlengd en geef prioriteit aan deze servers voor de uitrol van een verlengingsagent.

Beveiligingsteams

Controleer de certificaatsjablonen en SAN-beleidsregels die worden gebruikt voor Tomcat-registraties aan de hand van de huidige interne standaarden.
Vergelijk incidenten met certificaten met de DigiCert Trust Pulse-benchmark (45% downtime, 37.5% door verlopen certificaten) om de risico's voor de organisatie in kaart te brengen.

Platform-/infrastructuurteams

Documenteer het huidige pad naar de server.xml-sleutelopslag en het wachtwoordbeheerproces voor elke Tomcat-instantie.
Neem de back-up- en terugdraaistap op in standaard draaiboeken voor wijzigingsbeheer, niet alleen in deze ene handleiding.

Compliance

Controleer of het verlengingsbewijs (inschrijvings-ID, goedkeuring, implementatiegegevens) is vastgelegd voor controledoeleinden.
Markeer elk Tomcat-certificaat dat nog steeds een handmatige cyclus van 398 dagen of een jaar heeft als een risico-item vóór de limiet van 200 dagen in maart 2026.

Conclusie

Door de bovenstaande stappen te volgen, kunt u handmatig een certificaat vernieuwen voor elke website die op Apache Tomcat draait, zonder te hoeven gissen, ongeacht of de CSR rechtstreeks van CertSecure Manager komt of van een certificaat dat u al bezit. Handmatige vernieuwing is echter een tijdelijke oplossing, geen permanente strategie: aangezien de geldigheidsduur van publieke TLS-certificaten in maart 2029 daalt naar 47 dagen, is het herhalen van dezelfde stappen voor elke Tomcat-instantie in uw omgeving niet langer schaalbaar. Door een CertSecure Manager Renewal Agent op uw Tomcat-servers te implementeren, wordt dit handmatige proces volledig overbodig en blijven certificaten actueel zonder dat een geplande herstart nodig is.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit het artikel 'Certificaat vernieuwen op Apache Tomcat met CertSecure Manager'?

CertSecure Manager kan de CSR genereren, deze naar een verbonden CA verzenden en een kant-en-klaar PFX-bestand voor Apache Tomcat produceren. Zonder een Renewal Agent moet u echter nog steeds handmatig de keystore vervangen, server.xml indien nodig bijwerken en Tomcat herstarten om de verlenging te voltooien.

Waarom is dit belangrijk voor het beheer van de levenscyclus van bedrijfscertificaten?

Elke handmatige verlengingsstap is een moment waarop een gemiste deadline, een verkeerd bestandspad of een vertraagde herstart een storing kan veroorzaken. Op bedrijfsniveau, met honderden of duizenden certificaten, vormen handmatige Tomcat-verlengingen een van de grootste bronnen van vermijdbare downtime en hiaten in de auditprocedure van een certificaatlevenscyclusbeheerprogramma.

Welke teams zijn verantwoordelijk voor de uitvoering van deze richtlijnen?

PKI-teams beheren de CA Connector en de inschrijvingsconfiguratie, beveiligingsteams keuren de certificaatsjabloon en het SAN-beleid goed, platform- of infrastructuurteams voeren de wijziging en herstart van de server-side keystore uit en compliance-teams bevestigen dat de verlenging is geregistreerd en klaar is voor controle.

Welke risico's nemen toe als dit onderwerp handmatig wordt behandeld?

Handmatige verwerking vergroot het risico op gemiste verlengingstermijnen, onjuiste sleutelopslagpaden of wachtwoorden, ongeplande storingen tijdens herstart en inconsistente auditsporen. Uit een onderzoek van DigiCert, gepubliceerd op 2 juli 2025, bleek dat 45% van de organisaties melding maakte van downtime als gevolg van certificaten, waarvan 37.5% te wijten was aan verlopen certificaten.

Hoe vermindert automatisering het risico op certificaatuitval?

Een CertSecure Manager Renewal Agent elimineert de handmatige stappen van het downloaden van de CSR, het vervangen van de keystore en het herstarten door deze automatisch af te handelen vóór de vervaldatum. Hierdoor is het niet langer nodig dat iemand de verlengingsdatum onthoudt of elke stap correct uitvoert onder tijdsdruk.

Welke meetgegevens moeten teams bijhouden na de implementatie?

Houd de gemiddelde verlengingstijd bij, de verhouding tussen tijdige verlengingen en ongeplande verlopen, het aantal handmatig geopende tickets voor certificaatwerkzaamheden per kwartaal, het totale aantal beheerde certificaten en certificaatgerelateerde downtime-incidenten, gemeten ten opzichte van de branchenorm.

Hoe hangt dit samen met de gereedheid van het TLS-certificaat binnen 47 dagen?

Volgens CA/B Forum Ballot SC-081v3, aangekondigd op 14 april 2025, daalt de geldigheidsduur van openbare TLS-certificaten naar 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029. Een handmatig verlengingsproces voor jaarlijkse certificaten is niet schaalbaar naar een cyclus van 47 dagen, waardoor automatisering een vereiste is in plaats van een optionele upgrade.

Hoe moet dit worden aangepakt in multi-cloud- of hybride PKI-omgevingen?

Gebruik de CA-connectoren en certificaatdetectie van CertSecure Manager om inzicht te behouden in Tomcat-certificaten die zijn uitgegeven door meerdere openbare en particuliere CA's in cloud-, hybride en on-premises infrastructuren, in plaats van de certificaten van elke omgeving afzonderlijk te volgen.

Welke voorwaarden zijn nodig vóór de implementatie?

U hebt toegang nodig tot CertSecure Manager-inschrijving met een gekoppelde CA, beheerdersrechten voor de Tomcat-server, de huidige server.xml-connectorconfiguratie en het pad naar de keystore, een back-up van de bestaande keystore en een goedgekeurd onderhoudsvenster voor de herstart.

Welke schermafbeeldingen of configuratievoorbeelden moeten worden bijgevoegd?

Voeg het scherm 'Certificaat genereren' van CertSecure Manager toe, waarop de velden CA, sjabloon en SAN worden weergegeven, evenals het connectorblok server.xml met de waarden certificateKeystoreFile, certificateKeystorePassword en certificateKeystoreType die na verlenging moeten worden bijgewerkt.

Certificaat verlengen op Apache Tomcat met CertSecure Manager