Kui proovite SSL-i konfigureerida Apache'i või potentsiaalselt muu sarnase veebimajutustehnoloogia käitamiseks mõeldud serveris, võite lõpuks saada tõrke, mis ütleb, et serverisertifikaat EI sisalda serveri nimele vastavat ID-d. See on tehniliselt lihtsalt hoiatus ja teoreetiliselt võiksite sellega ümber käia.
Palju parem on teha väike tõrkeotsing, et asjad saaksid jälle tavapäraselt töötada. Kui olete serveri nime ja sertifikaadi kokku sobitanud, ei peaks te süsteemi järgmisel värskendamisel ühtegi neist toimingutest uuesti tegema. Kui faili lihtsa redigeerimisega ei saa asju parandada, peate võib-olla taastama mõned asjad, kuid kui olete selle teinud, ei pea te faile enam konfigureerima.
1. meetod: faili httpd [dot] conf muutmine
Alustuseks vaadake läbi 
fail, mis võib olla hoopis teises kohas, kui kasutate Apache Fedoras, Red Hatis või CentOS-is. Debiani ja Ubuntu serverid peaksid selle asuma sellel esimesel aadressil. Otsige teksti, mis kirjutab serverisertifikaadi EI sisalda ID-d, mis vastab serveri nime hoiatussõnumile.
Võib juhtuda, et see viskab 443 või mõne muu numbri välja IP-aadressi iga osa järel, kuid muid SSL-probleeme pole. Sel juhul ei pruugi te Apache'ile öelnud, milliseid sadamaid kuulata. Jookse
ja leidke rida, kus on kiri Listen 80. Selle alla lisage funktsioon Listen 443 või muu vajalik pordi number. Kui olete faili salvestanud ja sulgenud, saate seda kasutada 
httpd-protsessi taaskäivitamiseks.
Neil, kes käitavad Ubuntu või Debiani servereid, ei pruugi seda faili olla või võib see olla täiesti tühi, erinevalt neist, kes kasutavad mõnda Fedora või Red Hat Enterprise Linuxi versiooni. Sel juhul kasutage
kuulamisportide lisamiseks vajaliku tekstifaili muutmiseks.
Paljudel juhtudel oleks see pidanud probleemi lahendama. Kui ei, siis kontrollige enne sertifikaadi olukorra kontrollimist kõiki asjakohaseid võrguprobleeme.
2. meetod: uute sertifikaatide taastamine
Need hoiatussõnumid võivad ilmuda ka siis, kui olete töötanud aegunud sertifikaatidega, mille olete ise allkirjastanud. Kui peaksite neid taastama, proovige neid kasutada
ja otsige kahte rida, mis on tähistatud failiga ja võtmefailiga. Need ütlevad teile SSL-sertifikaadi loomisel, kus asub sertifikaadi võtmefaili asukoht.
Kui töötate professionaalse allakirjutanud ettevõttega, kes väljastab ametlikke veebisaidi sertifikaate, peaksite järgima litsentseeriva organisatsiooni konkreetseid juhiseid. Vastasel juhul peate seda tegema sudo openssl req -x509 -sõlmed -päevad 365 -newkey rsa: 2048 -keyout KeyFile -out File , asendades KeyFile ja File tekstiga, mille suutsite eelmisest kassi käsust välja saada. Oleksite pidanud leidma kahe erineva faili asukoha, mis toimivad sertifikaatide sisendis ja väljundis.
Eeldades, et nad olid aegunud, peaks vea parandamiseks piisama lihtsalt selle tegemisest, kuid peate võib-olla teenuse taaskäivitama, enne kui see lõpetab teile hoiatuste viskamise.
Samuti saate veidi rohkem teada saada praegu installitud sertifikaatide kohta, mis aitavad teil tõrkeotsingu protsessis osaleda. Kui soovite näha, mis nimi teie sertifikaadil praegu on, et see oleks vastavuses, võite käivitada openssl s_client -showcerts -ühendage $ {HOSTNAME}: 443 , kuigi sulude vahele tuleb panna tegelik hostinimi. Kui teil on probleeme mõne teise pordiga, asendage number 443.
Kui teil on mitu seadet installitud samasse seadmesse ja serveeritud samalt IP-aadressilt, peate käivitama openssl s_client -showcerts -ühendage $ {IP}: 443 -teenuse nimi $ {HOSTNAME} , asendades IP oma tegeliku IP-ga ja täites hostinime. Veelkord, peate võib-olla asendama 443 muu numbriga, et see vastaks teie konkreetsele kasutusjuhtumile.
Pidage meeles, et kui CSR loodi, peate tagama, et õige hostinimi määratakse varjunime või üldnimena.
3 minutit loetud
