Veebisait näitab vale sertifikaati? Leidke kuulaja

VPN-tarkvara paigaldamine veebimajutusele võib teenuseid ümber korraldada, kuid ootamatu sertifikaat ei tõesta, et Apache failid kirjutati üle. Miski esitas selle sertifikaadi teie brauserile ja esimene ülesanne on sellele nimi anda. Kuni kuulaja ja virtuaalhost pole tuvastatud, on iga parandus oletus, mis rakendatakse valele kihile. Kogu allolev kontroll on ainult lugemiseks.

Midagi ei taaskäivitata, desinstallita ega kirjutata üle, kuni kogute fakte, mis juhtumi otsustavad.

Lugege sertifikaati, mille brauser tegelikult sai

Kirjutage üles hostinimi, iga aadressiperekonna jaoks lahendatud aadress, port ja sertifikaadi üksikasjad, mille üle brauser kaebas. Nimi, mis lahendub nii A- kui ka AAAA-kirjeks, võib jõuda kahe erineva esikihini ja ainult üks neist võib olla host, millele teil on shell-ligipääs. Proksiserveri taga olev brauser võib jälle kolmanda tee valida. Arvamine, milline neist hoiatuse tekitas, raiskab ainsa tähelepaneku, mis teil on.

Seejärel korjake kätlus uuesti esile samal teel olevalt masinalt, nimetades aadressi selgesõnaliselt ja saates kavandatud serverinime, et vastus peegeldaks saiti, mitte vaikehosti.

openssl s_client -connect 198.51.100.37:443 -servername www.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -fingerprint -sha256 -ext subjectAltName

Võrrelge subjekti alternatiivseid nimesid ja sõrmejälge sertifikaadiga, mida ootate, mitte tuttava väljaandjaga. Ühendamine palja aadressiga ilma serverinimeta võib valida vaikesertifikaadi, mis siis paistab vale failina, kuigi tegelikult on vale küsimus.

Tehke kindlaks selle pordiga seotud protsess

Hostil, mis peaks ühenduse vastu võtma, loetlege kuulajad ning märkige sidumisaadress, aadressiperekond ja protsessi omanik. Loopback-aadressiga seotud teenus ei ole sama mis kõigi liidestega seotud teenus, ja konteineri avaldamine võib avaliku kuulaja hoopis mujale paigutada.

sudo ss -ltnp 'sport = :443'
sudo ss -ltnp | grep -E ':(443|943)\b'

Kui TLS-i lõpetab koormusjaotur või ees olev proksiserver, peatuge siin ja uurige hoopis seda esikihti. Taga olev Apache eksemplar ei pruugi avalikule brauserile kunagi sertifikaati esitada, mistõttu selle konfiguratsiooni muutmine ei muuda midagi sellest, mida brauser näeb. Socketite vaade ja väline kätlus peavad kirjeldama sama teed ja just seda see võrdlus tuvastab.

Sovitage virtuaalhost enne faili

Kui Apache on lõpetaja, küsige temalt, milline virtuaalhost selle aadressi ja nime jaoks võidab. Juhtkäsk trükib tegeliku paigutuse, sealhulgas igale socketile vastava grupi, deklareeritud serverinimed ja hosti, mida koheldakse vaikeväärtusena. Sertifikaadifaili muutmine ilma selle vastuseta on viis, kuidas vale sait hakkab teenindama õigest failist.

sudo apachectl -S

Apache SSL-i korduma kippuvad küsimused selgitavad, kuidas serverinime osutus sertifikaadi valib. HTTP Host-päis saabub pärast kätlust ega saa tagantjärele muuta seda, mis on juba esitatud, seega mittevastav või puuduv nimi langeb tagasi vaikehostile.

Nimega virtuaalhost, mille ServerAlias sisaldab kirjaviga, tekitab täpselt selle sümptomi, ja seda teeb ka teine konfiguratsioonifail, mis laadib esimesena kõike püüdva hosti. Mõlemad on selles paigutuse loendis nähtavad.

Kontrollige parandust igal väidetud teel

Pärast kinnitatud muudatust korrake hostinime-spetsiifilist kontrolli iga aadressiperekonna jaoks ja lõpetage brauseri tavapärase valideerimisega, mitte möödaviigulipuga. Enne jagatud kuulaja seadete puutumist hoidke eraldi haldustee, sest sealne viga eemaldab juurdepääsu, mida kasutaksite selle tagasivõtmiseks. Seejärel kirjutage üles, milline kuulaja vastas, milline virtuaalhost sobis ja milline sertifikaat enne ja pärast teenindati.

Paketi eemaldamine võib paigutust muuta ja jätta algse mittevastavuse seletamata, mistõttu see kirje elab parandusest kauem.

Mida te tahate, on kavandatud sait kavandatud sisenemispunktis. Teistsugune sertifikaat pärast seotud teenuse kadumist ei ole see tulemus, isegi kui brauser kaebamise lõpetab.