I'm hoping someone can provide me a bit of guidance about how AMT (and the Manageability Commander toolkit, in particular) goes about selecting client certificates when using TLS with mutual authentication.
I started by creating a self-signed root, using the "Certificate & CRL Store" facility in the Manageability Commander tool, then created a server cert signed by that root. Both certs used SHA-384 signature hashing with 2048-bit RSA keys. These appear to be correctly installed on the AMT target host: the "Certificates" panel in the Certificate Store dialog of Manageability Commander shows an "AMThost.subdomain.tld/myCA (TLS)" certificate and the "Trusted Roots" panel shows the "myCA" cert (the names have been changed here, but none of the actual text uses non-alphabetic characters).
My problems arise, I suspect, because the machine hosting the management console is not part of the Windows domain that will ultimately be used by the AMT target host (by which I mean that the target AMT host is being configured in an off-site lab), so there are DNS issues for both address resolution (I simply added "AMThost.subdomain.tld" to the workstation's etc/hosts file to provide "fake" DNS) and certificate selection. I used the Manageability Director tool to create a client cert using just the host name of the management box (i.e., "mgthost"). This certificate was created with all permissions enabled and appears in the Windows certificate store, as expected.
After enabling TLS in the Manageability Commander tool using the "AMThost.subdomain.tld/myCA" cert, I can connect to the target AMT host and manage it just fine. A lock icon appears next to the hostname on the connection tab to indicate that the server end of the connection has been verified, and SOL and console redirection work as expected.
If, however, I then add the remote authentication option, using a CN list with just "mgthost" in it (i.e., without a DNS suffix), the console reconnects to the AMT target machine and loads all parameters without incident, but, for reasons I have not been able to determine, SOL and the redirection ports no longer work. Any attempt to use them results in an instant failure (not a time-out). A "stack" trace of the call appears uneventful until local certificate selection is attempted, at which point the following log entries appear:
(information) RedirectionAlt:LocalCertificateSelection, targethost=AMThost.subdomain.tld
(error) RedirectionAlt:OpenSink failed, conID=0
(error) System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> System.ComponentModel.Win32Exception: The certificate chain was issued by an authority that is not trusted ...
Why is it that I can connect to the ME with this certificate set-up, but cannot use SOL or redirection? Everything else works just fine: I can even remotely change the TLS configuration back to server-only without going through an unprovision cycle at the AMT host.