1 Reply Latest reply on Jan 10, 2014 1:34 PM by kmkilbride

    AMT mutual authentication

    kmkilbride

      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.

        • 1. Re: AMT mutual authentication
          Alan Alderson

          When Commander connects to the client it can essentially ignore the "bad" certificate and connect anyway. However, when it comes time to establish a SOL or IDE-R connection, Commander needs to pass the certificate to the IMRSDK.dll. At this point Commander isn't able to ignore the "bad" certificate anymore, and you get an error.

          • 2. Re: AMT mutual authentication
            kmkilbride

            That does not appear to be the case.

             

            Firstly, it is the AMT host that appears to be rejecting the workstation's certificate, not the other way around. If mutual authentication is disabled, the workstation can connect to the AMT target just fine: a lock icon appears in the connection tab; viewing the remote certificate reveals the expected cert and security chain; no warnings or errors appear in the debug window, and everything works as expected. If Commander were ignoring an untrusted certificate offered by the AMT host and allowed the connection to continue in this manner despite having "accept non-TLS connections" unselected, I would consider it to be a very serious breach of confidence indeed.

             

            Secondly, if I delete the workstation's "real" authentication certificate (i.e., the one signed by the mutually-trusted root), then create a second self-signed root that is not trusted by the AMT target and use it to generate a workstation authentication certificate, it becomes impossible to do anything on the AMT target at all. You can "connect" to it, in a manner of speaking, but none of the remote parameters get downloaded and no actions can be taken whatsoever; moreover, the debug console immediately fills up with errors. A complete unprovision/reprovision cycle at the AMT console at the target is required to recover from this (unless you save the workstation's original client certificate, which I stupidly neglected to do).

             

            It really does look like parts of the Commander application are using one means of selecting authentication certificates to supply to the AMT target, while other parts of the application use a completely different means. The method used for managing base attributes works; the one used for everything else does not.

             

            What I'm wondering is if this implies that AMT mutual authentication cannot be used on workstations that are not part of a Windows domain. This would reduce its utility greatly for applications that are not Windows-centric.