Förstå ändringarna i rotcertifikatutfärdarändringen för Azure SQL Database och SQL Managed Instance

Azure SQL Database och SQL Managed Instance ändrar rotcertifikatet för klientprogrammet/drivrutinen som är aktiverat med Secure Sockets Layer (SSL) eller TLS (Transport Layer Security), som används för att upprätta en säker TDS-anslutning. Det aktuella rotcertifikatet är inställt på att upphöra att gälla den 26 oktober 2020 som en del av bästa praxis för standardunderhåll och säkerhet. Den här artikeln innehåller mer information om kommande ändringar, vilka resurser som påverkas och de steg som krävs för att säkerställa att programmet upprätthåller anslutningen till databasservern.

Vilken uppdatering kommer att ske?

Certifikatutfärdare (CA) Webbläsarforum publicerade nyligen rapporter om flera certifikat som utfärdats av CA-leverantörer för att vara icke-kompatibla.

Enligt branschens efterlevnadskrav började CA-leverantörer återkalla CA-certifikat för icke-kompatibla certifikatutfärdare, kräva att servrar använder certifikat som utfärdats av kompatibla certifikatutfärdare och signerats av CA-certifikat från dessa kompatibla certifikatutfärdare. Eftersom Azure SQL Database och SQL Managed Instance för närvarande använder ett av dessa icke-kompatibla certifikat, som klientprogram använder för att verifiera sina TLS-anslutningar, måste vi se till att lämpliga åtgärder vidtas (beskrivs nedan) för att minimera den potentiella påverkan på dina Azure SQL-servrar.

Det nya certifikatet används från och med den 26 oktober 2020. Om du använder fullständig validering av servercertifikatet när du ansluter från en SQL-klient (TrustServerCertificate=false) måste du se till att SQL-klienten kan verifiera ett nytt rotcertifikat före den 26 oktober 2020.

Hur gör jag för att veta om mitt program kan påverkas?

Alla program som använder SSL/TLS och verifierar rotcertifikatet måste uppdatera rotcertifikatet för att kunna ansluta till Azure SQL Database och Azure SQL Managed Instance.

Om du inte använder SSL/TLS för närvarande påverkas inte programtillgängligheten. Du kan kontrollera om klientprogrammet försöker verifiera rotcertifikatet genom att titta på anslutningssträng. Om TrustServerCertificate uttryckligen är inställt på sant påverkas du inte.

Om klientdrivrutinen använder OS-certifikatarkivet, som de flesta drivrutiner gör, och operativsystemet underhålls regelbundet kommer den här ändringen sannolikt inte att påverka dig, eftersom rotcertifikatet som vi växlar till redan ska vara tillgängligt i ditt betrodda rotcertifikatarkiv. Sök efter Baltimore CyberTrust Root och DigiCert GlobalRoot G2 Root och verifiera att den finns.

Om klientdrivrutinen använder det lokala filcertifikatarkivet, för att undvika att programmets tillgänglighet avbryts på grund av att certifikat oväntat återkallas eller för att uppdatera ett certifikat som har återkallats, läser du avsnittet Vad behöver jag göra för att upprätthålla anslutningen .

Vad behöver jag göra för att upprätthålla anslutningen

Följ dessa steg för att undvika att programmets tillgänglighet avbryts på grund av att certifikat oväntat återkallas eller för att uppdatera ett certifikat som har återkallats:

Vad kan effekten bli?

Om du verifierar servercertifikaten enligt beskrivningen här kan programmets tillgänglighet avbrytas eftersom databasen inte kan nås. Beroende på ditt program kan du få en mängd olika felmeddelanden, inklusive men inte begränsat till:

  • Ogiltigt certifikat/återkallat certifikat
  • Anslutningens tidsgräns uppnåddes
  • Fel om tillämpligt

Vanliga frågor och svar

Behöver jag fortfarande uppdatera rotcertifikatutfärdare om jag inte använder SSL/TLS?

Inga åtgärder för den här ändringen krävs om du inte använder SSL/TLS. Du bör ändå ange en plan för att börja använda den senaste TLS-versionen när vi planerar för TLS-tillämpning inom en snar framtid.

Vad händer om jag inte uppdaterar rotcertifikatet före den 26 oktober 2020?

Om du inte uppdaterar rotcertifikatet före den 30 november 2020 kommer dina program som ansluter via SSL/TLS och verifierar för rotcertifikatet inte att kunna kommunicera med Azure SQL Database och SQL Managed Instance och programmet får anslutningsproblem med din Azure SQL Database och SQL Managed Instance.

Behöver jag planera ett underhållsavbrott för den här ändringen?

Nej. Eftersom ändringen endast är på klientsidan för att ansluta till servern behövs ingen underhållsavbrottstid här för den här ändringen.

Vad händer om jag inte kan få en schemalagd stilleståndstid för den här ändringen före den 26 oktober 2020?

Eftersom klienterna som används för att ansluta till servern måste uppdatera certifikatinformationen enligt beskrivningen i avsnittet åtgärda här behöver vi i det här fallet inte ha någon stilleståndstid för servern.

Kommer jag att påverkas om jag skapar en ny server efter den 30 november 2020?

För servrar som skapats efter den 26 oktober 2020 kan du använda det nyligen utfärdade certifikatet för dina program för att ansluta med SSL/TLS.

Hur ofta uppdaterar Microsoft sina certifikat eller vad är förfalloprincipen?

Dessa certifikat som används av Azure SQL Database och SQL Managed Instance tillhandahålls av betrodda certifikatutfärdare (CA). Så stödet för dessa certifikat på Azure SQL Database och SQL Managed Instance är kopplat till stöd för dessa certifikat av CA. Men som i det här fallet kan det finnas oförutsedda buggar i dessa fördefinierade certifikat, som måste åtgärdas tidigast.

Om jag använder skrivskyddade repliker behöver jag bara utföra den här uppdateringen på den primära servern eller alla skrivskyddade repliker?

Eftersom den här uppdateringen är en ändring på klientsidan måste vi även tillämpa ändringarna för dessa klienter om klienten använde för att läsa data från replikservern.

Har vi frågor på serversidan för att kontrollera om SSL/TLS används?

Eftersom den här konfigurationen är på klientsidan är information inte tillgänglig på serversidan.

Vad händer om jag har fler frågor?

Om du har en supportplan och behöver teknisk hjälp skapar du En Azure-supportbegäran. Mer information finns i Skapa Azure-supportbegäran.