Från och med version 17.32.160 LTS, 20.0 PROD och 17.33.270 BETA har Invantive SQL ändrat standardinställningarna för anslutningar till MySQL, PostgreSQL och SQL Server för att upprätthålla kryptering av datatransport med SSL. Denna artikel ger några tips om korrekt konfiguration av certifikat. De är dock endast förslag. Rådfråga din databasadministratör, säkerhetsansvarig eller IT-leverantör för djupare kunskap och tillämpning på din lokala situation.
Från och med 20.0.112 och 20.1.261 BETA har standardinställningarna för SQL Server finjusterats: standardkryptering är avstängd när en SQL Server-databehållare registreras från upptäckten och antingen nås med hjälp av rördrivrutinen (Windows intern databas) eller datakällan/servernamnet inte har någon decimalpunkt (‘.’). Detta förenklar första användningen, eftersom få bläddringsbara lokala SQL Server-instansenheter med korrekt certifikatkonfiguration existerar.
Typiskt SQL Server Fel
Efter en uppgradering kan du stöta på ett fel med kod itgenclr038, itgenclr121 eller itgenase498 som:
provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.
Eller
SSL Provider, error: 0 - The target principal name is incorrect.
Typiskt PostgreSQL Fel
På PostgreSQL kan du stöta på ett fel som:
Remote certificate validation failed
eller ett itgenclr072 med text som:
AuthenticationException
Exception while performing SSL handshake.
The remote certificate was rejected by the provided RemoteCertificateValidationCallback.
eller ett itgenclr139 fel som:
SSL connection requested. No SSL enabled connection from this host is configured.
Typiskt MySQL Fel
På MySQL kan du stöta på ett fel som:
The host SOMETHING does not support SSL connections.
Tillvägagångssätt
De rekommenderade stegen för sådana problem är:
- Konfigurera korrekt transportkryptering.
- Kontrollera med din säkerhetsansvarig om okrypterad och osäker datatransport mellan din Invantive SQL-nod och databasen är tillåten.
- Om så är fallet, inaktivera den nu standardmässiga krypteringen.
Konfigurera Transportkryptering
Transportkrypteringen måste konfigureras på klienten som etablerar anslutningen. Med lokala produkter är detta servern eller enheten som används för att köra Invantive-produkten. Invantive online-produkter erbjuder olika mängder konfigurationsmöjligheter, men att ladda egna eller icke-standardcertifikat är typiskt sett inte möjligt.
Azure
På Azure tillhandahåller Microsoft som standard de nödvändiga certifikaten på servern som accepteras som standard på Microsoft Windows.
Se till att du använder rätt värdnamn, såsom myname.database.windows.net.
Amazon
På Amazon kan det vara nödvändigt att ladda certifikatkedjan på din klient. Följ AWS-instruktionerna, som vanligtvis är:
- Ladda ner AWS:s offentliga nyckel från https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem.
- Konvertera den till ett certifikat med hjälp av https://www.sslshopper.com/ssl-converter.html (konvertera till PKCS#7/P7B).
- Importera p7b-filen i ditt certifikatslager.
Självhanterad server
För on-premise och självhanterade servrar, vänligen kontakta din lokala administratör.
Inaktivera Standardkryptering
Dessa steg beskriver hur du inaktiverar en begäran om kryptering initierad av klientprogramvaran genom att ändra anslutningssträngen. Både databasserver och klient måste enas om kryptering, så det är inte alltid möjligt att tillhandahålla enbart en klientlösning.
Platsen för anslutningssträngen varierar, men i de flesta implementationsscenarier finns den i settings*.xml-filer (formatbeskrivning). Dessa finns vanligtvis i mappen %USERPROFILE%\invantive; läs kunskapsbasartikeln 7208961 för mer information.
Inom settings*.xml-filer kan anslutningssträngen förekomma som en del av en databehållardefinition som:
<database
...
connectionString="Server=dbhost.com;Initial Catalog=database;Persist Security Info=False;User ID=user;Password=secret;Connection Timeout=30;"
Och i attribut som den anslutningssträng som används för Invantive Data Replicator:
dataCacheConnectionString="provider=SqlServer;connectionString={Server=dbhost.com;Database=database;User Id=user;Password=secret}"
Invantive-dokumentationen innehåller mer bakgrundsinformation om hur du ställer in settings*.xml-filer. Alternativt kan din lokala databasadministratör hjälpa dig.
SQL Server Ändring
Som ett första steg kan du vilja fortsätta använda kryptering men tillåta vissa attacker genom att ändra din anslutningssträng för att inkludera:
hostNameInCertificate=*.domain.name
Alternativt kan du vilja fortsätta använda kryptering men tillåta fler attacker som exempelvis man-in-the-middle-attacker genom att ändra din anslutningssträng för att inkludera:
TrustServerCertificate=True
Som en sista utväg, inaktivera kryptering helt genom att använda:
Encrypt=false
SQL Server Exempel
Till exempel, att helt inaktivera SQL Server-kryptering i anslutningssträngen som en del av en databehållardefinition angiven ovan leder till:
<database
...
connectionString="Encrypt=false;Server=dbhost.com;Initial Catalog=...original..."
Och för SQL Server som används för att lagra Invantive Data Replicator-förrådet angiven ovan:
dataCacheConnectionString="provider=SqlServer;connectionString={Encrypt=false;Server=...original...}"
PostgreSQL
Som ett första steg kan du vilja fortsätta använda kryptering men tillåta fler attacker som exempelvis man-in-the-middle-attacker genom att ändra din anslutningssträng för att inkludera:
Trust Server Certificate=True
Som en sista utväg, tillåt att inaktivera kryptering genom att använda:
SslMode=Prefer
MySQL
Som ett första steg kan du vilja fortsätta använda kryptering men tillåta fler attacker som exempelvis man-in-the-middle-attacker genom att ändra din anslutningssträng för att inkludera:
SslMode=VerifyCA
Som en sista utväg, tillåt att inaktivera kryptering genom att använda:
SslMode=Preferred