Problém
SQL Server umí používat SSL certifikát na to, aby se šifrovaly SQL dotazy i odpovědi. Pokud žádný vhodný nenajde, automaticky si vygeneruje self-signed certifikát a začne ho používat. Špatné na tom je, že klienti takovému certifikátu nevěří a šifrování tedy nepoužívají. Lepší by bylo přidělit SQL serveru důvěryhodný doménový certifikát, ale to chce trošku práce.
Nejprve se pro jistotu podívejte do logu na SQL serveru, že tam najdete následující událost ohledně toho zmíněného, automaticky vygenerovaného, certifikátu:
Event log: Application
Event ID: 26018
Source: MSSQL$...
Description: A self-generated certificate was successfully loaded for encryption.
My se tedy pokusíme zařídit, aby SQL server používal automaticky nějaký důvěryhodný certifikát od vaší doménové autority. To ale není úplně jednoduché. Funguje to tak, že pokud SQL server nalezne v úložišti vhodný certifikát, tak ho rovnou použije. Jenže to právě není tak jednoduché, aby ho nalezl :-) Jestli se skutečně nějaký našel, zjistíte podle jiné události:
Event log: Application
Event ID: 26013
Source: MSSQL$...
Description: The certificate [Cert Hash (sha-1) ...] was successfully loaded for encryption.
Poznámka pro zájemce o SHA-2. Ano, SQL server umí používat certifikáty podepsané SHA-2. To co vidíte v předchozí události je jen informace o algoritmu, jímž byl vypočten otisk certifikátu (thumprint, fingerprint) a nikoliv jeho digitální podpis. Windows generují otisky vždy pomocí SHA-1, protože v tomhle případě se vůbec nejedná o bezpečnostní záležitost.
Požadavky na certifikát
Potřebujete standardní SSL serverový certifikát (Server Authentication). Musí být uložen v úložišti počítače (ideálně), nebo v úložišti servisního účtu, pod kterým běží příslušná instance SQL serveru. Musí být samozřejmě platný.
Upozorňuju, že nesmí být vydán pomocí šablony certifikátů verze 3 (Certificate Template v3) - tedy nesmíte to vytvářet jako šablonu pro Windows Server 2008 - protože CNG (Cryptography Next Generation) není prozatím podporována ani ve verzi SQL Server 2008 R2. Znovu opakuju, že certifikát může být podepsán pomocí SHA-2 (na to CNG nepotřebujete)
Autoenrollment a servisní účty
Ideálně ten certifikát vydávejte pomocí technologie autoenrollment pro počítač, na kterém běží daný SQL server. Říkám pro počítač. I když vám instance toho SQL serveru běží pod nějakým vyhrazeným servisním účtem, vydávejte pro počítač. Servisním účtům totiž autoenrollment nefunguje a museli byste ten certifikát každý rok vydávat ručně a přenastavovat ho v SQL Server Configuration Manager.
Ok. Takže vydáváme automaticky. Jenže nastane problém, pokud vám SQL server běží pod nějakým servisním účtem (service account). Pokud ten servisní účet není členem lokální skupiny Administrators, tak nebude mít k vydanému certifikátu přístup. Musíte mu ho tedy přidělit. Což uděláte z příkazové řádky. Já si na to vždycky naplánuju úlohu (scheduled task), která běží při startu a pak pravidelně třeba každou hodinu.
CERTUTIL -v -repairstore my <Certificate Template CN Name>
"D:PAI(A;;GAGR;;;SY)(A;;GAGR;;;BA)(A;;GR;;;<Service Account SID>)"
Předchozí příkaz nastaví oprávnění (securit descriptor) na všech certifikátech vydaných podle příslušné <certificate template cn name> tak, že SYSTEM, Administrators a váš servisní účet mohou používat jeho privátní klíče. Pro položku <Certificate Template CN Name> použijte systémové jméno šablony. Nepoužívejte takové to zobrazované jméno (displayName), které obsahuje mezery, tomu systém nerozumí.
Jak zjistíte SID do položky <Service Account SID>? Například si stáhněte utilitu PSGETSIT z Microsoftu, ta vám ho řekne. Samozřejmě můžete použít i nějakou skupinu. Třeba v případě, že vám na jednom stroji běží víc SQL instancí současně pod různými účty.
Oprávnění na certifikátu si můžete prohlédnout a změnit i v certifikátové MMC konzoli (MMC, Certificates, Local Computer) pomocí volby Manage private keys.