Certificaat verlengen op Apache met CertSecure Manager

Kort antwoord: Het vernieuwen van een certificaat op Apache met CertSecure Manager houdt in dat er een TLS-certificaat wordt gegenereerd of opnieuw wordt geregistreerd via CertSecure Manager, het ondertekende PFX-bestand wordt gedownload, de privésleutel en het certificaat worden uitgepakt met OpenSSL en beide bestanden worden geïmplementeerd op de Apache-server voordat de service opnieuw wordt opgestart om de wijziging toe te passen. Wanneer dit proces handmatig op honderden servers wordt uitgevoerd, is het de belangrijkste oorzaak van vermijdbare certificaatstoringen.

Apache blijft een van de meest gebruikte webservers in bedrijfsomgevingen, en elke website die erop draait, is afhankelijk van een geldig en correct geïnstalleerd TLS-certificaat. Deze handleiding beschrijft de volledige vernieuwingsworkflow met behulp van CertSecure Manager, het platform voor certificaatlevenscyclusbeheer (CLM) van Encryption Consulting, en voegt de vereisten, terugdraaistappen, foutafhandeling en succesindicatoren toe die een PKI-, beveiligings-, platform- of compliance-team nodig heeft om dit veilig en op grote schaal uit te voeren.

Voorwaarden en een beknopte checklist

Controleer de onderstaande punten voordat u met de verlenging begint. Het missen van een van deze punten is de meest voorkomende oorzaak van een mislukte of vertraagde verlenging.

Checklist met vereisten

• Actief CertSecure Manager-account met inschrijvingsrechten en toegang tot de doel-CA en certificaatsjabloon.
• Beheerderstoegang of sudo-toegang tot de doel-Apacheserver.
• OpenSSL moet geïnstalleerd zijn op de machine die gebruikt wordt om de sleutel en het certificaat te extraheren (v1.1.1 of later; v3.x wordt ondersteund met de -legacy vlag voor PKCS#12-compatibiliteit)
• Kennis van het PFX-exportwachtwoord dat is ingesteld tijdens het genereren van het certificaat.
• De huidige Apache virtuele hostconfiguratie toont de bestaande SSLCertificateFile en SSLCertificateKeyFile paden
• Een onderhoudsvenster of een periode met weinig verkeer, aangezien Apache opnieuw moet worden opgestart om het nieuwe certificaat te laden.
• Maak een back-up van de huidige certificaat- en sleutelbestanden voordat u ze overschrijft.

Tabel met voorwaarden voor actie

Eerste vereiste	Actie ondernemen vóór verlenging	Eigenaar
CertSecure Manager-toegang	Bevestig de inschrijvingsrol en de CA/sjabloontoewijzing.	PKI-team
Toegang tot de Apache-server	Controleer de sudo/admin-referenties en de SSH-toegang.	Platformteam
Beschikbaarheid van OpenSSL	Bevestig de versie en de ondersteuning voor oudere providers.	Platformteam
Bestaande configuratiepaden	Zoek SSLCertificateFile en SSLCertificateKeyFile in de vhost-configuratie.	Platformteam
backup	Kopieer de huidige .crt- en .key-bestanden naar een locatie waar de back-up kan worden hersteld.	Platformteam
Venster wijzigen	Plan de herstart tijdens een periode met weinig verkeer.	Beveiliging/Wijzigingsbeheer
Nalevingsrecord	Registreer de verlenging in de certificaatinventaris/CBOM voor auditdoeleinden.	Complianceteam

Certificaatbeheer met CertSecure Manager

CertSecure Manager is het platform voor certificaatlevenscyclusbeheer (CLM) van Encryption Consulting. Het pakt de kernuitdaging aan waar organisaties mee te maken hebben bij het beheren van PKI: het enorme aantal certificaten in de infrastructuur, van certificaatdetectie en geautomatiseerde verlenging tot het afdwingen van organisatiebrede uitgiftebeleid. Integraties met ServiceNow en Microsoft Teams ondersteunen workflows voor waarschuwingen en incidentbeheer, zodat een naderende vervaldatum nooit afhangt van iemand die een spreadsheet moet raadplegen.

CertSecure Manager scheidt gebruikersgegevens per afdeling en rol. Beheerders definiëren beleid en wijzen rollen toe, en gebruikers kunnen alleen de acties uitvoeren die hun machtigingen toestaan. Dit zorgt ervoor dat certificaatbewerkingen traceerbaar blijven binnen grote teams.

Met een architectuur voor hoge beschikbaarheid (HA) integreren de connectorclients van CertSecure Manager alle openbare en private CA's in één overzichtelijk dashboard. De workflows van de vernieuwingsagent ondersteunen Apache, Tomcat, nginx en loadbalancers zoals F5, waardoor vernieuwde certificaten automatisch worden geïmplementeerd zonder handmatige tussenkomst op de endpoints die dit ondersteunen. Deze automatisering dicht ook de lacune die de handmatige stappen in deze handleiding blootleggen: elke handmatige stap hieronder is een stap die de vernieuwingsagent van CertSecure Manager overbodig maakt voor ondersteunde Apache-implementaties.

Certificaatlevenscyclusbeheer stopt niet bij TLS. Hetzelfde probleem van ontdekking en inventarisatie geldt voor elk cryptografisch asset in een omgeving, en dat is waar een cryptografische stuklijst (CBOM) relevant wordt. CBOM Secure van Encryption Consulting breidt de ontdekking van certificaten uit naar een volledige inventarisatie van crypto-assets, en de handleiding 'CBOM inventory-to-intelligence' beschrijft hoe die inventarisatie wordt omgezet in bruikbare crypto-flexibiliteit.

Stapsgewijze handleiding voor het verlengen van een Apache-certificaat

Er zijn twee ondersteunde manieren om een ​​certificaat voor een website die op Apache wordt gehost te vernieuwen. Ten eerste kunt u een nieuw Certificate Signing Request (CSR) genereren in CertSecure Manager. Dit creëert een nieuwe privésleutel en een CSR met de domeinnaam, organisatienaam en andere subjectgegevens, waarna deze wordt ingediend bij een certificeringsinstantie (CA) voor validatie en uitgifte. Ten tweede kunt u zich rechtstreeks aanmelden vanuit een bestaande CSR. In dat geval hoeft u geen nieuwe CSR te genereren en kunt u de bestaande CSR direct naar de CA sturen.

CertSecure Manager automatiseert de arbeidsintensieve onderdelen van dit acquisitieproces, waardoor de handmatige stappen hieronder worden teruggebracht tot configuratie en implementatie aan de Apache-kant.

Stap 1: Genereer het certificaat in CertSecure Manager.

Meld u aan bij CertSecure Manager en ga naar 'Certificaat genereren' onder het gedeelte 'Inschrijving' in het menu aan de linkerkant. Selecteer de juiste CA, certificaatsjabloon, SAN-kenmerken en eventuele andere vereiste velden en klik vervolgens op 'Certificaat genereren'.

Verwacht resultaat: een nieuwe inschrijvingstaak verschijnt in het inschrijvingsoverzicht met de status 'in behandeling' of 'uitgevoerd'.

Stap 2: Download het certificaat uit de inschrijvingslijst.

Ga naar de inschrijvingsinventaris en zoek het certificaat op met behulp van de inschrijvings-ID (controleer 'Taken' als het niet direct zichtbaar is). Download het PFX-bestand en zet het over naar de Apache-server of naar het werkstation dat u gaat gebruiken om de bestanden voor te bereiden.

Verwachte uitkomst: a .pfx Een bestand met het certificaat, de certificaatketen en de privésleutel, beveiligd door het exportwachtwoord dat u tijdens de registratie hebt ingesteld.

Stap 3: Extraheer de privésleutel en het certificaat met OpenSSL.

Apache heeft de privésleutel en het certificaat nodig als aparte PEM-bestanden, niet als een gecombineerd PFX-bestand. Haal eerst de privésleutel eruit:

Met dit commando wordt een versleutelde privésleutel gegenereerd. Voor een onversleutelde sleutel voegt u het volgende toe: -nodes:

OpenSSL zal om het PFX-exportwachtwoord vragen dat is ingesteld toen het certificaat werd gegenereerd. Vervolgens extraheert u het certificaat zelf, ofwel met OpenSSL of door de certificaatexport te hernoemen naar een .pem uitbreiding:

Verwachte uitkomst: twee bestanden, key.pem en certificate.pem, klaar voor inzet.

Veelvoorkomende fout: op OpenSSL 3.x, waarbij het volgende wordt weggelaten -legacy Dit kan een "Mac-verificatiefout" veroorzaken wanneer het PFX-bestand is gegenereerd met de verouderde RC2/3DES-versleuteling. -legacy Laadt de legacy-provider en lost het probleem op.

Stap 4: Implementeer het certificaat en de sleutel op de Apache-server.

Ons salon certificate.pem en key.pem in hetzelfde pad waar het huidige certificaat en de sleutel voor de site zijn opgeslagen, met dezelfde bestandsnamen en machtigingen als Apache al verwacht (meestal aangeduid met SSLCertificateFile en SSLCertificateKeyFile (in de vhost-configuratie). Maak een back-up van de vorige bestanden voordat u ze overschrijft.

Verwachte uitkomst: De vhost-configuratie verwijst naar het nieuwe certificaat en de nieuwe sleutel, en de bestandsrechten komen overeen met die van de vorige bestanden (meestal 600 (voor de privésleutel, die eigendom is van de Apache-servicegebruiker).

Stap 5: Apache opnieuw starten en controleren

Test de configuratie voordat u opnieuw opstart:

Als de test slaagt, start u de service opnieuw:

Controleer of het nieuwe certificaat actief is en check de vervaldatum:

Verwachte uitkomst: apachectl configtest retourneert "Syntax OK", de site laadt zonder certificaatwaarschuwing en de afgedrukte tekst notAfter De datum komt overeen met de geldigheidsperiode van het nieuwe certificaat.

Operationele workflow voor en na

Stadium	Handmatig proces (voorheen)	Met CertSecure Manager-automatisering (daarna)
De reis van mijn leven	Het bijhouden van gegevens via een spreadsheet kan ertoe leiden dat je een certificaat over het hoofd ziet.	Gecentraliseerde inventarisatie in alle aangesloten CA's.
Inschrijving	Handmatige CSR-generatie en -indiening per certificaat	Beleidsgestuurde inschrijving via CertSecure Manager
Sleutel-/certificaatextractie	Handmatige OpenSSL-opdrachten per server	Afgehandeld door de verlengingsagent voor ondersteunde servers, waaronder Apache.
Deployment	Handmatige bestandsplaatsing en toegangscontrole	Geautomatiseerde implementatie via verlengingsagent
Herstart	Handmatig gepland en uitgevoerd	Gecoördineerd als onderdeel van de geautomatiseerde workflow
Alarmering	Ad-hoc herinneringen of geen	ServiceNow/Teams-waarschuwingen bij verlopen en fouten
Controlespoor	Handmatig onderhouden, vaak onvolledig	Automatisch geregistreerd in CertSecure Manager en CBOM-inventaris.

Eigenaar- en actiematrix

Team	Verantwoordelijkheid in deze workflow	Belangrijkste actie
PKI-team	Beheert de relaties met CA, sjablonen en het inschrijvingsbeleid.	Configureer CertSecure Manager-sjablonen en keur het inschrijvingsbereik goed.
Beveiligingsteam	Verantwoordelijk voor risicobeoordeling en incidentafhandeling bij certificaatstoringen.	Stel drempelwaarden voor vervalwaarschuwingen in en analyseer de oorzaken van storingen achteraf.
Platform-/infrastructuurteam	Beheert de Apache-servers en voert de implementatie uit.	Voer de implementatie-, herstart- en verificatiestappen uit of automatiseer deze.
Complianceteam	Beschikt over auditbewijs voor controles met betrekking tot de levenscyclus van certificaten.	Controleer of de verlengingsgebeurtenissen zijn geregistreerd in de inventaris/CBOM voor auditdoeleinden.

Richtlijnen voor terugdraaien

Als het nieuwe certificaat een storing of verkeerde configuratie veroorzaakt, kunt u de back-up terugzetten die in stap 4 is gemaakt.

1. Herstel de vorige certificate.pem en key.pem van back-up naar de oorspronkelijke bestandspaden.
2. Controleer of het eigenaarschap en de machtigingen van het bestand overeenkomen met de situatie vóór de wijziging (doorgaans 600 voor de privésleutel).
3. lopen apachectl configtest Controleer of de configuratie geldig is voordat u opnieuw opstart.
4. Herstart Apache en controleer of de site opnieuw laadt met het herstelde certificaat.
5. Onderzoek de oorzaak van de fout (verlopen certificaatketen, onjuiste sleutel, verkeerd SAN-nummer) voordat u de verlenging opnieuw probeert.
6. Registreer de terugdraaigebeurtenis in de certificaatinventaris, zodat het auditspoor weergeeft wat er daadwerkelijk is gebeurd.

Veelvoorkomende fouten en hoe u ze kunt vermijden

Fout	waarschijnlijke oorzaak	Bepalen
"Mac-verificatiefout: ongeldig wachtwoord?" tijdens PKCS#12-extractie	OpenSSL 3.x maakt standaard gebruik van een provider die de oudere encryptie van de PFX niet ondersteunt.	Voeg de -legacy vlag toevoegen aan het OpenSSL-commando
Apache start niet op na de implementatie.	Certificaat en privésleutel komen niet overeen, of het bestandspad in de vhost-configuratie is onjuist.	Controleren SSLCertificateFile/SSLCertificateKeyFile paden en bevestig dat de sleutel overeenkomt met het certificaat. openssl x509 -noout -modulus en openssl rsa -noout -modulus
De browser toont nog steeds het oude certificaat.	Apache is niet opnieuw opgestart, of een cachingproxy/CDN ervoor gebruikt nog steeds het oude certificaat.	Controleer of de herstart is voltooid en wis eventuele CDN/proxy-cache.
Certificaat verloopt opnieuw eerder dan verwacht	De geldigheidsperiode wordt verkeerd begrepen in het kader van het steeds korter wordende schema van het CA/B Forum.	Bevestig de afgegeven geldigheidsperiode aan de hand van de huidige CA/B Forum-fase (200/100/47 dagen) in plaats van uit te gaan van de vorige standaardperiode van 398 dagen.

Successtatistieken om bij te houden

• Aantal downtime-incidenten met betrekking tot certificaten per kwartaal (doel: nul, vergeleken met de 45% van de organisaties die in het DigiCert-onderzoek van 2025 minstens één incident meldden).
• Percentage van verlengingen voltooid vóór de vervaldatum versus erna (doel: 100% vóór de vervaldatum)
• Gemiddelde verlengingstijd per certificaat, handmatig versus geautomatiseerd
• Aantal certificaten onder geautomatiseerde verlenging versus handmatige registratie
• Daling van het aantal handmatig verlengde tickets per kwartaal.
• Auditbevindingen met betrekking tot verlopen of verkeerd geconfigureerde certificaten (doel: nul)

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

Een enkel verlopen certificaat op een Apache-server in een productieomgeving kan een website die toegankelijk is voor klanten platleggen, en dit is geen zeldzaamheid. Uit de Trust Pulse Survey van DigiCert uit juli 2025 bleek dat 45% van de organisaties het afgelopen jaar te maken heeft gehad met downtime als gevolg van certificaten, en dat 37.5% van deze storingen specifiek werd veroorzaakt door verlopen certificaten ( DigiCert, 2 juli 2025 ). Handmatige vernieuwingsworkflows zoals de hierboven beschreven zijn noodzakelijk om te begrijpen, maar ze zijn niet schaalbaar voor de grote hoeveelheden certificaten die de meeste bedrijven tegenwoordig beheren.

Onze mening: teams moeten de handmatige stappen in deze handleiding beschouwen als een gedocumenteerde noodoplossing en een trainingsreferentie, niet als het standaard werkmodel. Elke onderneming die Apache op grote schaal gebruikt, zou certificaatvernieuwing moeten automatiseren met een CLM-workflow, zowel om het bovengenoemde risico op uitval te elimineren als omdat de geldigheidsperiode van certificaten steeds korter wordt, waardoor handmatige vernieuwing onhoudbaar is, ongeacht de discipline binnen het team.

Verbinding maken met de gereedheid van het 47-daagse TLS-certificaat

CA/B Forum Ballot SC-081v3, gesponsord door Sectigo en aangenomen in april 2025, verlaagt de maximale geldigheidsduur van openbare TLS-certificaten van 398 dagen naar 200 dagen vanaf 15 maart 2026, 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029 ( Sectigo, 14 april 2025 ). Bij een interval van 47 dagen zou een handmatig vernieuwingsproces zoals beschreven in deze handleiding ongeveer acht keer per jaar per certificaat moeten worden uitgevoerd, voor elke Apache-instantie in de omgeving.

Dit is hetzelfde probleem met crypto-flexibiliteit als bij post-quantummigratie: beide vereisen een exacte kennis van alle certificaten en cryptografische activa voordat ze snel beheerd kunnen worden. CBOM Secure van Encryption Consulting bouwt die certificaatdetectie en crypto-activa-inventarisatie op, en het PQC Center of Excellence en de PQC- gereedheidsprogramma's breiden diezelfde discipline uit naar quantumveilige algoritmemigratie. Het automatiseren van de verlenging van Apache-certificaten via CertSecure Manager is nu een directe voorbereiding op het eindpunt van 47 dagen van dit schema.

Wat te doen Volgende

Voor PKI-teams

Controleer welke Apache-servers nog steeds afhankelijk zijn van handmatige vernieuwing en bevestig dat de CertSecure Manager-sjablonen en CA-verbindingen al deze servers dekken.

Voor beveiligingsteams

Stel de drempelwaarden voor vervalwaarschuwingen ruim vóór de vervaldatum van 47 dagen in en evalueer de incidenten met betrekking tot certificaten van de afgelopen vier kwartalen aan de hand van de bovenstaande succesindicatoren.

Voor platformteams

Test de verlengingsagent van CertSecure Manager eerst op een niet-kritieke Apache-instantie voordat u deze in het hele netwerk uitrolt, en documenteer de terugdraaiprocedure naast het standaard draaiboek.

Voor compliance-teams

Zorg ervoor dat gebeurtenissen met betrekking tot verlenging en terugdraaiing worden vastgelegd in de certificaatinventaris, zodat automatisch auditbewijs voor levenscyclusbeheer wordt gegenereerd in plaats van achteraf te worden gereconstrueerd.

Conclusie

Het vernieuwen van een certificaat op Apache met CertSecure Manager is eenvoudig zodra de bovenstaande stappen voor inschrijving, extractie en implementatie zijn gedocumenteerd en geoefend. Maar naarmate de geldigheidsperioden van certificaten korter worden, richting 47 dagen, en het aantal certificaten blijft groeien, is het handmatig uitvoeren van deze stappen geen haalbaar operationeel model meer voor de lange termijn. Beschouw deze handleiding als referentie voor hoe het proces werkt en de automatische vernieuwingsfunctie van CertSecure Manager als de manier om dit veilig en op grote schaal uit te voeren. Bekijk hoe dezelfde workflow werkt op andere servertypen in onze handleiding voor het vernieuwen en intrekken van certificaten in Microsoft PKI.

Veelgestelde Vragen / FAQ

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

Het vernieuwen van een Apache-certificaat omvat het genereren of registreren van een certificaat in CertSecure Manager, het downloaden van het PFX-bestand, het extraheren van de sleutel en het certificaat met OpenSSL, het implementeren van beide op de server en het herstarten van Apache. Het handmatige proces werkt wel, maar is niet schaalbaar. Daarom automatiseert de vernieuwingsagent van CertSecure Manager dit proces voor ondersteunde Apache-implementaties.

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

Certificaatstoringen komen vaak voor en zijn kostbaar. Uit de Trust Pulse Survey van DigiCert uit juli 2025 bleek dat 45% van de organisaties het afgelopen jaar te maken heeft gehad met downtime als gevolg van certificaatproblemen, waarbij 37.5% van de incidenten terug te voeren was op verlopen certificaten. Apache-implementaties op bedrijfsniveau vergroten dit risico, omdat één gemiste verlenging een productiesite plat kan leggen.

Welke teams zijn verantwoordelijk voor de uitvoering van deze richtlijnen?

Doorgaans delen vier teams de verantwoordelijkheid: het PKI-team beheert de CA-relaties en inschrijvingssjablonen, het beveiligingsteam is verantwoordelijk voor de waarschuwingsdrempels en de incidentanalyse, het platformteam voert de implementatie en herstarts uit en het compliance-team controleert of verlengingsgebeurtenissen worden vastgelegd voor auditdoeleinden.

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

Handmatige verlenging vergroot het risico op gemiste vervaldatums, niet-overeenkomende sleutels en certificaten, onjuiste bestandsrechten en onvolledige auditsporen. Naarmate de geldigheidsperioden korter worden volgens het gefaseerde schema van het CA/B Forum, neemt de frequentie van handmatige verlengingen per certificaat toe, waardoor de kans op menselijke fouten bij elke stap groter wordt.

Hoe vermindert automatisering het risico op certificaatuitval?

De workflow van de vernieuwingsagent van CertSecure Manager elimineert de handmatige stappen voor extractie, implementatie en herstart voor ondersteunde servers, waaronder Apache, en vervangt ad-hoc tracking door gecentraliseerde waarschuwingen voor verlopen certificaten via integraties zoals ServiceNow en Microsoft Teams. Dit overbrugt de kloof tussen het moment waarop een certificaat moet worden vernieuwd en het moment waarop er daadwerkelijk actie wordt ondernomen.

Welke meetgegevens moeten teams bijhouden na de implementatie?

Registreer per kwartaal incidenten met betrekking tot uitval van certificaten, het percentage verlengingen dat vóór versus na de vervaldatum is voltooid, de gemiddelde verlengingstijd, het aantal certificaten dat geautomatiseerd versus handmatig wordt beheerd, de afname van handmatige verlengingsaanvragen en eventuele auditbevindingen met betrekking tot verlopen of verkeerd geconfigureerde certificaten.

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

CA/B Forum Ballot SC-081v3 verkort de maximale geldigheidsduur van openbare TLS-certificaten tot 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029. Bij een interval van 47 dagen wordt handmatige verlenging onpraktisch, waardoor de in deze handleiding beschreven automatisering een directe voorwaarde is om te voldoen aan het steeds korter wordende schema.

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

In multi-cloud- en hybride omgevingen is het aan te raden alle certificaatregistratie en -vernieuwing, ongeacht waar de Apache-instantie draait, via één CLM-platform zoals CertSecure Manager te laten verlopen in plaats van elke cloud- of on-premises omgeving afzonderlijk te beheren. Dit zorgt ervoor dat CA-relaties, sjablonen en auditsporen consistent blijven in alle omgevingen, in plaats van gefragmenteerd te zijn per platform.

Welke voorwaarden zijn nodig vóór de implementatie?

Teams hebben toegang nodig tot CertSecure Manager voor inschrijving, beheerdersrechten voor de Apache-server, OpenSSL geïnstalleerd met ondersteuning voor oudere providers, de huidige vhost-configuratiepaden, het PFX-exportwachtwoord, een gepland onderhoudsvenster voor de herstart en een back-up van de bestaande certificaat- en sleutelbestanden.

Welke schermafbeeldingen of configuratievoorbeelden moeten worden bijgevoegd?

De documentatie moet het scherm 'Certificaat genereren' van CertSecure Manager bevatten, de weergave 'Inschrijvingsinventaris' die wordt gebruikt om het PFX-bestand te vinden en te downloaden, de terminaluitvoer voor elk OpenSSL-extractiecommando en de relevante Apache vhost-configuratieregels die verwijzen naar de paden naar de certificaat- en sleutelbestanden.