Korjaa SQL Serverin salausvirhe – yhden napsautuksen ratkaisu
SQL Server muodostaa yhteyden ja kieltäytyy sitten kirjautumasta sisään, koska se ei voi luottaa palvelimen varmenteeseen. Tämä ei ole verkko-ongelma ja tietosi eivät ole kadonneet - se on luottamusongelma. Käsittele korjaukset videon esittämässä järjestyksessä: nopea asiakaspuolen vaihtoehto, sama kytkin sovelluksen yhteysmerkkijonon sisällä ja oikea korjaus itse palvelimella.
📑Lukuja
- Kirjautumisvirhe - "Varmenneketjun on myöntänyt viranomainen, johon ei ole luotettu"
- Mitä virhe todella tarkoittaa - salausta vaaditaan, palvelimen varmenne ei voi todistaa sen henkilöllisyyttä
- Asiakkaan pikakorjaus – Luota palvelimen varmenteeseen SSMS-yhteysikkunassa
- Sama korjaus sovelluksen yhteysmerkkijonossa
- Oikea korjaus – anna palvelimelle todellinen varmenne, johon asiakkaat luottavat yksin
- Korjauksen tarkistaminen – yhdistä uudelleen tarkasti ja todista, että salaus on todella käytössä
📋 Yleiskatsaus ja vaiheittaiset ohjeet
Lue virhe - se on luottamusongelma, ei verkko-ongelma
Verkkosi on kunnossa ja palvelin toimii. Yhteys saavutti SQL Serverin, palvelin tarjosi salatun kanavan kirjautumiseen, ja tietokoneesi kieltäytyi siitä, koska palvelimen henkilöllisyyden todistava varmenne on allekirjoittanut kukaan, johon tietokoneesi luottaa. SSMS:n koko virheilmoitus on:
Oletusarvoisesti SQL Server suojaa kirjautumisen itse allekirjoitetulla varmenteella, jonka se luo itse. Itseallekirjoitettu varmenne salaa liikenteen, mutta se ei voi todistaa, että palvelin on todella sinun palvelimesi, joten vahvistettua salausta vaativat asiakkaat hylkäävät sen. Jokainen rehellinen korjaus on yksi kahdesta asiasta: aseta asiakas hyväksymään tämä palvelin tietoisesti (vaiheet 2 ja 3) tai anna palvelimelle varmenne, johon asiakkaat luottavat yksin (vaihe 4).
Pikaasiakaskorjaus SSMS:ssä - Trust Server Certificate
Tämä on videolla näkyvä nopea reitti. Se ei muuta palvelimella mitään; se käskee tämän yhden yhteyden hyväksymään palvelimen varmenteen tarkistamatta sen allekirjoittajaa. Napsauta Yhdistä palvelimeen -ikkunassa Asetukset avataksesi lisävälilehdet, siirry Yhteyden ominaisuudet -välilehteen, aseta salaukseksi Pakollinen (tai jätä se tarjotuksi), valitse Luotettava palvelinsertifikaatti ja napsauta Yhdistä. Kirjautuminen menee heti läpi.
Sama korjaus sovelluksen yhteysmerkkijonon sisällä
Jos sovellus epäonnistuu SSMS:n sijaan, sama kytkin elää sen yhteysmerkkijonossa. Lisää nämä kaksi asetusta nimenomaisesti - Encrypt=True ottaa suojatun kanavan käyttöön ja TrustServerCertificate=True on SSMS-valintaruudun yhteysmerkkijonon oikeinkirjoitus:
Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;Käytä omaa palvelimen nimeä, tietokantaa ja kirjautumistunnusta esimerkkiarvojen sijasta. Kompromissi on täsmälleen sama kuin vaiheen 2 valintaruutu, ja siinä on yksi ylimääräinen vaara: toimitetun sovelluksen kokoonpanoon sisällytettynä ohitettu tarkistus koskee jokaista käyttäjää, näkymättömästi ja pysyvästi. Säilytä se kehitys- ja väliasennuskokoonpanoissa ja käsittele sitä tuotannossa laina-aikana, kunnes vaiheessa 4 oleva palvelinvarmenne on paikallaan.
Salauksen oletuksena käyttöön. Yhteysmerkkijonot, jotka eivät koskaan maininneet salausta, alkoivat vaatia sitä palvelimia vastaan, joiden itse allekirjoitetut varmenteet eivät läpäise vahvistusta. Mikään tietokannassasi ei muuttunut; merkkijonon sisällä oleva sopimus teki. Asetusten kirjoittaminen nimenomaisesti tarkoittaa, että seuraava ohjainpäivitys ei voi muuttaa sovelluksesi toimintaa selkäsi takana.Oikea korjaus - Anna palvelimelle todellinen sertifikaatti
Pysyvä korjaus tapahtuu kerran, palvelimella, ja sen jälkeen jokainen asiakas muodostaa tiukasti yhteyden ilman valintaruutua ja varoitusta. Hanki ensin varmenne palvelimen koko DNS-nimelle (esimerkiksi sql01.company.local) sisäiseltä varmenteen myöntäjältä tai julkiselta varmentajalta palvelimen todennus-käytöllä. Tuo se yksityisen avaimensa kanssa SQL Server -koneen Paikallisen tietokoneen-sertifikaattisäilöön. Napsauta sitten varmennetta hiiren kakkospainikkeella, valitse Kaikki tehtävät → Hallitse yksityisiä avaimia ja myönnä SQL Server -palvelutilille yksityisen avaimen lukuoikeus. Avaa SQL Server Configuration Manager, laajenna SQL Server Network Configuration, napsauta hiiren kakkospainikkeella Protocols for MSSQLSERVER, valitse Properties ja valitse varmenne Sertifikaatti-välilehdellä. Liput-välilehdellä voit myös määrittää ForceEncryption-asetukseksi Kyllä, jotta jokaisen asiakkaan on salattava. Käynnistä SQL Server -palvelu uudelleen – muutos ei tee mitään, ennen kuin teet sen.
Tarkista Korjaa tiukka tapa
Hiljaisesti onnistunut sisäänkirjautuminen todistaa vähemmän kuin ihmiset luulevat, koska jotkut asetusyhdistelmät muodostavat yhteyden ilman todellista suojaa. Todista molemmat puolikkaat. Muodosta ensin yhteys asiakkaaseen uudelleen tiukasti: muodosta yhteys käyttämällä palvelimen DNS-nimeä – varmenteen sisällä olevaa nimeä – aseta salaukseksi Pakollinen ja jätä Luottamuspalvelimen sertifikaatti valitsematta. Kirjautumisen pitäisi onnistua ilman varoitusta. Kysy sitten samassa istunnossa palvelimelta, onko yhteys todella salattu suorittamalla tämä kysely SSMS:ssä:
SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;encrypt_option, jossa TRUE on läpäissyt arvosana. EPÄTOSI toimivalla sisäänkirjautumisella tarkoittaa, että yhteys on onnistunut poistamalla suojaus, eikä työtä ole tehty. Tämä läpäisytesti on todellinen maaliviiva: kaikki oikein konfiguroidut asiakkaat, mukaan lukien tulevat SSMS-versiot, muodostavat nyt yhteyden täydellä validoinnilla ilman erityisiä asetuksia.
🏷️Aihehaun muuttujat ja avainsanat
🎙️ Täysi transkriptio – laajenna napauttamalla
__TOK_24__
__TOK_25__
__TOK_26__
❓ Usein kysytyt kysymykset
Onko tämä opetusohjelma 100% ilmainen seurata?
__TOK_27__
Voivatko aloittelijat seurata tätä ohjetta?
__TOK_28__
Mistä voin esittää kysymyksiä, jos jään jumiin?
__TOK_29__