Ko poskušate konfigurirati SSL na strežniku, namenjenem zagonu Apacheja ali potencialno druge podobne tehnologije spletnega gostovanja, lahko na koncu dobite napako, ki pove, da potrdilo strežnika NE vsebuje ID-ja, ki se ujema z imenom strežnika. To je tehnično le opozorilo in teoretično bi se lahko potrudili.
Veliko boljša ideja je, da malo odpravite težave, da bodo stvari spet delovale kot običajno. Ko sta ime strežnika in potrdilo usklajena, vam ne bo treba ponoviti nobenega od teh korakov, ko boste naslednjič posodobili sistem. Morda boste morali nekaj stvari regenerirati, če preprosto urejanje datotek stvari ne bo popravilo, vendar ko boste to storili, vam ne bo treba več konfigurirati datotek.
1. način: Urejanje datoteke httpd [dot] conf
Začnite s pogledom skozi 
datoteko, ki je namesto tega lahko nekoliko drugačna, če uporabljate Apache v Fedora, Red Hat ali CentOS. Strežnika Debian in Ubuntu bi morala biti na tem prvem naslovu. Poiščite besedilo, v katerem je zapisano potrdilo strežnika, NE vsebuje ID-ja, ki se ujema z opozorilnim sporočilom imena strežnika.
Morda boste ugotovili, da po vsakem delu naslova IP vrže 443 ali drugo številko, ne pa drugih težav s SSL. V tem primeru morda Apacheju niste povedali, katera vrata naj poslušajo. Teči
in poiščite vrstico, ki se glasi Listen 80. Pod njo dodajte Listen 443 ali katero koli drugo številko vrat, ki jo morda potrebujete. Ko datoteko shranite in zaprete, jo lahko uporabite 
za ponovni zagon procesa httpd.
Tisti, ki uporabljajo strežnike Ubuntu ali Debian, te datoteke morda nimajo ali pa se jim zdi, da je popolnoma prazna, za razliko od tistih, ki uporabljajo nekatere različice Fedore ali Red Hat Enterprise Linux. V tem primeru uporabite
za urejanje besedilne datoteke, ki je potrebna za dodajanje vrat za poslušanje.
V mnogih primerih bi to moralo odpraviti težavo. V nasprotnem primeru preverite vse ustrezne težave z mreženjem, preden nadaljujete s pregledom stanja certifikata.
2. način: Obnavljanje novih potrdil
Ta opozorilna sporočila se lahko pojavijo tudi, če ste delali s potečenimi potrdili, ki ste jih podpisali sami. Če jih boste morali regenerirati, poskusite uporabiti
in poiščite dve vrstici z oznako File in KeyFile. Ti bodo povedali, kje je lokacija datoteke s ključem potrdila, ko ustvarjate potrdilo SSL.
Če sodelujete s strokovnim podjetjem, ki podpisuje uradna potrdila svetovnega spleta, upoštevajte posebna navodila, ki jih je izdala vaša licenčna organizacija. V nasprotnem primeru boste morali sudo openssl req -x509 -nodes -days 365 -newkey rsa: 2048 -keyout KeyFile -out File , nadomestite KeyFile in File z besedilom, ki ste ga dobili iz prejšnjega ukaza cat. Morali bi najti lokacijo dveh različnih datotek, ki služita na vhodu in izhodu za potrdila.
Ob predpostavki, da so bili zastareli, bi že samo to početje zadostovalo za odpravo napake, vendar boste morda morali znova zagnati storitev, preden ne bo več opozarjal na vas.
Prav tako lahko izveste nekaj več o certifikatih, ki ste jih trenutno namestili in vam pomagajo pri odpravljanju težav. Če si želite ogledati, katero ime je trenutno na vašem potrdilu, da se zagotovi njegovo ujemanje, lahko zaženete openssl s_client -showcerts -connect $ {HOSTNAME}: 443 , vendar boste morali v oklepaje postaviti svoje dejansko ime gostitelja. Če imate težave z drugimi vrati, zamenjajte številko 443.
Če imate v isti napravi nameščenih več potrdil in jih strežite z istega naslova IP, boste morali zagnati openssl s_client -showcerts -connect $ {IP}: 443 -ime strežnika $ {HOSTNAME} , zamenjava IP z vašim dejanskim IP in izpolnitev imena gostitelja. Še enkrat boste morda morali zamenjati 443 z drugo številko, da se bo ujemala z vašim primerom uporabe.
Upoštevajte, da morate zagotoviti, da se pravilno ime gostitelja določi kot vzdevek ali splošno ime, ko je bil CSR sploh ustvarjen.
3 minute branja
