Når du forsøger at konfigurere SSL på en server designet til at køre Apache eller potentielt en anden lignende webhostingteknologi, kan du muligvis få en fejl, der fortæller dig, at servercertifikatet IKKE indeholder et ID, der matcher servernavnet. Dette er teknisk set kun en advarsel, og du kan teoretisk arbejde dig rundt omkring det.
Det er en meget bedre idé at lave en lille fejlfinding for at få tingene til at fungere igen som normalt. Når du har matchet servernavnet og certifikatet, skal du ikke gøre noget af disse trin igen, næste gang du opdaterer systemet. Det kan være nødvendigt at gendanne et par ting, hvis en simpel filredigering ikke løser ting, men når du har gjort det, behøver du ikke konfigurere filer yderligere.
Metode 1: Redigering af httpd [dot] conf-filen
Start med at kigge igennem
fil, som i stedet muligvis kan være et lidt andet sted, hvis du kører Apache på Fedora, Red Hat eller CentOS. Debian- og Ubuntu-servere skal have den placeret på denne første adresse. Se efter tekst, der staver servercertifikatet, der IKKE indeholder et ID, der svarer til advarselsmeddelelsen om servernavnet.
Du kan måske finde ud af, at det smider 443 eller et andet nummer ud efter hver del af IP-adressen, men ingen andre SSL-problemer. I dette tilfælde har du muligvis ikke fortalt Apache om, hvilke porte du skal lytte til. Løb
og find en linje, der læser Lyt 80. Under den skal du tilføje Lyt 443 eller det andet portnummer, du måtte have brug for. Når du har gemt og lukket filen, kan du bruge den 
for at genstarte httpd-processen.
Dem, der kører Ubuntu- eller Debian-servere, har muligvis ikke denne fil, eller de kan finde ud af, at den er helt tom, i modsætning til dem, der bruger nogle versioner af Fedora eller Red Hat Enterprise Linux. Brug i så fald
for at redigere den tekstfil, der er nødvendig for at tilføje porte, du kan lytte til.
I mange tilfælde skulle dette have rettet problemet. Hvis ikke, skal du kontrollere alle relevante netværksproblemer, inden du fortsætter med at inspicere certifikatsituationen.
Metode 2: Regenerering af nye certifikater
Disse advarsler kan også komme op, hvis du har arbejdet med udløbne certifikater, som du selv har underskrevet. Hvis du har brug for at regenerere dem, kan du prøve at bruge
og se efter to linjer markeret File og KeyFile. Disse fortæller dig, hvor placeringen af certifikatnøglefilen er, når du opretter et SSL-certifikat.
Hvis du arbejder med et professionelt underskrivende firma, der leverer officielle World Wide Web-certifikater, skal du følge de specifikke instruktioner fra din licensorganisation. Ellers skal du sudo openssl req -x509 -knudepunkter -dage 365 -nykey rsa: 2048 -keyout KeyFile -out-fil, erstatter KeyFile og File med den tekst, som du var i stand til at komme ud af den forrige kat-kommando. Du skulle have fundet placeringen af to forskellige filer, der fungerer ved input og output for certifikaterne.
Hvis vi antager, at de var forældede, skulle det bare være nok at rette fejlen, hvis du gør dette, men du bliver muligvis nødt til at genstarte tjenesten, inden den holder op med at smide advarsler mod dig.
Du kan også finde ud af lidt mere om de certifikater, som du i øjeblikket har installeret for at hjælpe dig i fejlfindingsprocessen. For at se, hvilket navn der i øjeblikket er på dit certifikat for at sikre, at det matcher, kan du køre openssl s_client -showcerts -connect $ {HOSTNAME}: 443, selvom du bliver nødt til at placere dit faktiske værtsnavn mellem parenteserne. Udskift 443-tallet, hvis du har problemer med en anden port.
Hvis det er tilfældet, at du har flere certifikater installeret på den samme enhed og serveret fra den samme IP-adresse, skal du køre openssl s_client -showcerts -connect $ {IP}: 443 -servernavn $ {HOSTNAME}, erstatte IP med din faktiske IP og udfylde værtsnavnet. Endnu en gang skal du muligvis udskifte 443 med et andet tal for at matche din specifikke brugssag.
Husk, at du skal sikre dig, at det korrekte værtsnavn bliver angivet som et alias eller det fælles navn, når CSR oprindeligt blev oprettet.
