SqlSecureConnection: Unable to specify certificate by using friendly name about sqlserverdsc HOT 5 OPEN

I'd suggest adding CommonName parameter instead of FriendlyName. In some cases (e.g. Let's Encrypt), we may not control/know exact certificate's friendly name.

Alternatively, have the resource allow matching the friendly name against a pattern.

In case of multiple certificate matches (with either solution), use the certificate with the latest expiration date.

from sqlserverdsc.

Suggest adding a new parameter FriendlyName and use the command Assert-BoundParameter so the resource throws and exception if both parameters are provided in the configuration. Thumbprint should no longer be required. But one of Thumbprint or FriendlyName should be passed otherwise the resource should also throw an exception. Assert-BoundParameter can be used for that verification too. Though, saw that there were a bug in the docs, says the wrong command name for that parameter set. Fixed.

from sqlserverdsc.

What about adding the FriendlyName as @johlju suggested but also the CommonName as @bozho mentioned. But for this the Assert-BoundParameter can't validate mutual exclusion of 3 parameters, right?

from sqlserverdsc.

We should use only common name as @bozho suggests.

from sqlserverdsc.

This will also solve the issue of certificate auto-rotation. Instead of hard pinning the thumbprint the next installed certificate can be used as soon as it's available.
As mentioned choose the latest ValidTo, if ValidFrom and ValidTo are current.

from sqlserverdsc.