Tests | Remove hardcoded credentials from ManualTests

[edwardneal]

This PR mops up almost all of the remaining hardcoded credentials, and does three things:

• Removes references to CertificateUtility.CreateCertificate, which always used a hardcoded certificate.
• Forces the tests to dynamically generate keys in Azure Key Vault.
• Removes references to CertificateUtilityWin in CspProviderExt, then the class itself.

Removal of hardcoded credentials

The removal of CertificateUtility.CreateCertificate is pretty uncontroversial. However, the AKVTest.TestRoundTripWithAKVAndCertStoreProvider test tries to round-trip encrypted column data, encrypting it with the hardcoded certificate and decrypting it with the Azure Key Vault key. I've thus treated this key as another static credential and removed it.

It's worth noting that the CoreCryptoTests class loads hardcoded credentials from TCECryptoNativeBaselineRsa.txt. I've not touched this because I don't know what to do with it. It isn't testing any SqlClient-specific functionality, just .NET's ability to decrypt text which is encrypted by native code. I'm not sure whether this is necessary any more though: we already test this implicitly with the end-to-end AE tests. There's no modification required here - just a choice on whether to keep or delete the test entirely.

CspProviderExt tests

One partially-related change was to remove CertificateUtilityWin. This was only ever used by the CspProviderExt tests, which used RSACryptoServiceProvider to generate a key in a specific CSP and encrypt/decrypt data with it. This consisted of three tests:

1. TestKeysFromCertificatesCreatedWithMultipleCryptoProviders, which looked for all CSPs with a name containing "RSA and AES", then generated a key in that CSP and tested the Always Encrypted provider with it.
2. TestRoundTripWithCSPAndCertStoreProvider, which generated a certificate and tried to round-trip between the certificate-based AE provider and the CSP-based AE provider. XUnit was already being told to skip this test.
3. TestEncryptDecryptWithCSP, which did exactly the same thing as test 1, but with a hard-coded CSP of "Microsoft Enhanced RSA and AES Cryptographic Provider".

Tests 1 and 3 are actually identical. "Microsoft Enhanced RSA and AES Cryptographic Provider" is the only CSP which fits the criteria for Test 1. I've thus eliminated test 1, and modified test 3 to run against all matching CSPs.

Of the remaining two tests, TestEncryptDecryptWithCSP would run a PowerShell script to generate a certificate, then extract the private key and use this as the CSP. It didn't need to do this, it could simply instantiate an RSACryptoServiceProvider directly and use that. I've thus eliminated the certificate generation. The round-trip test did need the certificate though, so I've just switched it to use the same certificate generation fixture as the rest of the tests. It still fails if I force it to run, but it fails with the same error as before. Once these changes were done, CertificateUtilityWin was no longer referenced and could be deleted wholesale.

The CspProviderExt/CertificateUtilityWin changes comprise around half of the changes. If it's easier to review, I can split them into a separate PR.