Når du prøver å konfigurere SSL på en server designet for å kjøre Apache eller potensielt en annen lignende webhotellteknologi, kan det hende du får en feil som forteller deg at serversertifikatet IKKE inneholder en ID som samsvarer med servernavnet. Dette er teknisk sett bare en advarsel, og du kan teoretisk arbeide deg rundt det.
Det er en mye bedre idé å gjøre litt feilsøking for å få ting til å fungere som normalt. Når du har matchet servernavnet og sertifikatet, trenger du ikke å gjøre om noen av disse trinnene neste gang du oppdaterer systemet. Du må kanskje regenerere noen få ting hvis en enkel filredigering ikke løser ting, men når du har gjort det, trenger du ikke å konfigurere filer lenger.
Metode 1: Redigering av httpd [dot] conf-filen
Start med å se gjennom
fil, som i stedet kan være på et litt annet sted hvis du kjører Apache på Fedora, Red Hat eller CentOS. Debian- og Ubuntu-servere skal ha den plassert på denne første adressen. Se etter tekst som staver ut serversertifikatet inneholder IKKE en ID som samsvarer med servernavnet.
Du kan oppdage at det kaster ut 443 eller et annet nummer etter hver del av IP-adressen, men ingen andre SSL-problemer. I dette tilfellet har du kanskje ikke fortalt Apache om hvilke porter du skal lytte til. Løpe
og finn en linje som lyder Lytt 80. Under den, legg til Lytt 443 eller hva annet portnummer du måtte trenge. Når du har lagret og lukket filen, kan du bruke den 
for å starte httpd-prosessen på nytt.
De som kjører Ubuntu- eller Debian-servere, har kanskje ikke denne filen, eller de kan finne den helt tom, i motsetning til de som bruker noen versjoner av Fedora eller Red Hat Enterprise Linux. Bruk i så fall
for å redigere tekstfilen som trengs for å legge til porter å lytte til.
I mange tilfeller burde dette ha løst problemet. Hvis ikke, så sjekk alle relevante nettverksproblemer før du fortsetter for å inspisere sertifikatsituasjonen.
Metode 2: Regenerere nye sertifikater
Disse advarslene kan også komme opp hvis du har jobbet med utløpte sertifikater som du signerte selv. Hvis du trenger å regenerere dem, kan du prøve å bruke
og se etter to linjer merket File og KeyFile. Disse vil fortelle deg hvor sertifikatnøkkelfilen ligger når du oppretter et SSL-sertifikat.
Hvis du jobber med et profesjonelt undertegnende firma som leverer offisielle sertifikater på internett, bør du følge de spesifikke instruksjonene gitt av lisensieringsorganisasjonen din. Ellers må du sudo openssl req -x509 -noder -dager 365 -nøkkel rsa: 2048 -keyout KeyFile -out-fil, erstatter KeyFile og File med teksten du klarte å få ut av den forrige cat-kommandoen. Du burde ha funnet plasseringen til to forskjellige filer, som fungerer ved inngang og utgang for sertifikatene.
Forutsatt at de var utdaterte, skulle det bare være nok å gjøre feilen for å fikse feilen, men du må kanskje starte tjenesten på nytt før den slutter å kaste advarsler mot deg.
Du kan også finne ut mer om sertifikatene du for øyeblikket har installert for å hjelpe deg i feilsøkingsprosessen. For å se hvilket navn det er på sertifikatet ditt for å sikre at det samsvarer, kan du kjøre openssl s_client -showcerts -connect $ {HOSTNAME}: 443, men du må sette ditt faktiske vertsnavn mellom parentesene. Bytt ut 443-tallet hvis du har problemer med en annen port.
Hvis du har flere sertifikater installert på samme enhet og servert fra samme IP-adresse, må du kjøre openssl s_client -showcerts -connect $ {IP}: 443 -servernavn $ {HOSTNAME}, erstatte IP med din faktiske IP og fylle ut vertsnavnet. Nok en gang må du kanskje erstatte 443 med et annet tall for å matche din spesifikke brukssak.
Husk at du må sørge for at riktig vertsnavn blir spesifisert som et alias eller fellesnavn når CSR ble opprettet i utgangspunktet.
