[BUG] Activate fails with "not running LMS" on AMT 19.0.5 — TLS Bad Certificate on localhost:16993

[like-shock]

RPC-Go v2.48.16 fails to activate on Intel AMT 19.0.5 (CSME 19) with the error not running lms, even though the LMS service is running and healthy. The root cause is a TLS handshake failure when RPC-Go connects to LMS on localhost:16993 — Go's TLS client rejects the AMT self-signed certificate because it is not in the system's trusted CA store.

Environment

• RPC-Go version: v2.48.16
• AMT version: 19.0.5
• OS: Windows
• LMS: Running (confirmed via sc query LMS)

Steps to Reproduce

1. Install RPC-Go v2.48.16 on a machine with AMT 19.0.5
2. Confirm LMS is running
3. Run rpc activate -u wss://<server>/activate -n --profile <profile>
4. Observe not running lms error

Expected Behavior

RPC-Go should successfully connect to LMS via localhost:16993 and proceed with activation.

Actual Behavior

RPC-Go reports not running lms and activation fails.

Root Cause Analysis (Packet Capture)

A packet capture on port 16993 reveals the following TLS handshake flow:

| Direction | Content

-- | -- | --
1 | RPC-Go → LMS | Client Hello (SNI=localhost, TLS 1.2/1.3)
2 | LMS → RPC-Go | Server Hello (TLS 1.2 selected)
3 | LMS → RPC-Go | Certificate — Intel® AMT self-signed certificate (issuer: Intel Corporation, CN=Intel® AMT self-signed certificate, valid 2022-01-01 to 2037-12-31, RSA 2048-bit, CA:TRUE)
4 | LMS → RPC-Go | Server Key Exchange + Server Hello Done
5 | RPC-Go → LMS | Fatal Alert: Bad Certificate (42)
6 | RPC-Go → LMS | FIN

Key observations:

• The Bad Certificate alert (code 42) is sent by the client (RPC-Go), not the server.
• The server does not send a CertificateRequest, so this is not a mutual TLS issue.
• The server certificate is a valid self-signed certificate with appropriate extensions (serverAuth EKU, digitalSignature + keyEncipherment + keyCertSign key usage).
• The certificate is not expired (valid until 2037).

Conclusion: Go's crypto/tls client performs certificate chain verification by default. Since the AMT self-signed certificate is not in the system's trusted root CA store, the TLS handshake fails with Bad Certificate. RPC-Go then interprets this connection failure as "LMS not running."

Context: AMT 19 TLS-Only Requirement

Starting with Intel CSME 19 firmware (Arrow Lake platforms), all connections to Intel AMT — including local connections — must use TLS (port 16993). Non-TLS port 16992 is no longer supported under any circumstances.

Reference: Intel Non-TLS End-of-Life Notification

This means RPC-Go must properly handle TLS connections to LMS on localhost, including accepting the AMT self-signed certificate.

Suggested Fix

For the localhost LMS connection, add InsecureSkipVerify: true to the tls.Config:

tlsConfig := &tls.Config{
    InsecureSkipVerify: true, // Safe for localhost LMS communication
}

Rationale: This is a localhost-only connection to the local LMS/AMT Management Engine. There is no man-in-the-middle risk on the loopback interface. The AMT self-signed certificate is generated by the ME firmware and cannot be replaced with a CA-signed certificate through normal means.

Alternative approaches:

1. Extract the AMT self-signed certificate at runtime and add it to a custom RootCAs pool for the TLS config — more secure but adds complexity.
2. Document that users must manually add the AMT self-signed certificate to their system's trusted root CA store — works but is a poor user experience and must be repeated per device.

Workaround

Users can manually add the AMT self-signed certificate to the system's trusted root CA store:

# Extract the certificate
openssl s_client -connect localhost:16993 -servername localhost < nul 2>nul | openssl x509 -outform PEM > amt_self_signed.crt
Add to Windows trusted root store (requires admin)
certutil -addstore "Root" amt_self_signed.crt

Attachments

• Packet capture file (16993.pcapng) is available upon request.

# [BUG] Activate fails with "not running LMS" on AMT 19.0.5 — TLS Bad Certificate on localhost:16993

Description

RPC-Go v2.48.16 fails to activate on Intel AMT 19.0.5 (CSME 19) with the error not running lms, even though the LMS service is running and healthy. The root cause is a TLS handshake failure when RPC-Go connects to LMS on localhost:16993 — Go's TLS client rejects the AMT self-signed certificate because it is not in the system's trusted CA store.

Environment

• RPC-Go version: v2.48.16
• AMT version: 19.0.5
• OS: Windows
• LMS: Running (confirmed via sc query LMS)

Steps to Reproduce

1. Install RPC-Go v2.48.16 on a machine with AMT 19.0.5
2. Confirm LMS is running
3. Run rpc activate -u wss://<server>/activate -n --profile <profile>
4. Observe not running lms error

Expected Behavior

RPC-Go should successfully connect to LMS via localhost:16993 and proceed with activation.

Actual Behavior

RPC-Go reports not running lms and activation fails.

Root Cause Analysis (Packet Capture)

A packet capture on port 16993 reveals the following TLS handshake flow:

#	Direction	Content
1	RPC-Go → LMS	Client Hello (SNI=localhost, TLS 1.2/1.3)
2	LMS → RPC-Go	Server Hello (TLS 1.2 selected)
3	LMS → RPC-Go	Certificate — Intel® AMT self-signed certificate (issuer: Intel Corporation, CN=Intel® AMT self-signed certificate, valid 2022-01-01 to 2037-12-31, RSA 2048-bit, CA:TRUE)
4	LMS → RPC-Go	Server Key Exchange + Server Hello Done
5	RPC-Go → LMS	Fatal Alert: Bad Certificate (42)
6	RPC-Go → LMS	FIN

Key observations:

• The Bad Certificate alert (code 42) is sent by the client (RPC-Go), not the server.
• The server does not send a CertificateRequest, so this is not a mutual TLS issue.
• The server certificate is a valid self-signed certificate with appropriate extensions (serverAuth EKU, digitalSignature + keyEncipherment + keyCertSign key usage).
• The certificate is not expired (valid until 2037).

Conclusion: Go's crypto/tls client performs certificate chain verification by default. Since the AMT self-signed certificate is not in the system's trusted root CA store, the TLS handshake fails with Bad Certificate. RPC-Go then interprets this connection failure as "LMS not running."

Context: AMT 19 TLS-Only Requirement

Starting with Intel CSME 19 firmware (Arrow Lake platforms), all connections to Intel AMT — including local connections — must use TLS (port 16993). Non-TLS port 16992 is no longer supported under any circumstances.

Reference: [Intel Non-TLS End-of-Life Notification](https://www.intel.com/content/www/us/en/support/articles/000089852/technologies/intel-active-management-technology-intel-amt.html)

This means RPC-Go must properly handle TLS connections to LMS on localhost, including accepting the AMT self-signed certificate.

Suggested Fix

For the localhost LMS connection, add InsecureSkipVerify: true to the tls.Config:

tlsConfig := &tls.Config{
    InsecureSkipVerify: true, // Safe for localhost LMS communication
}

Rationale: This is a localhost-only connection to the local LMS/AMT Management Engine. There is no man-in-the-middle risk on the loopback interface. The AMT self-signed certificate is generated by the ME firmware and cannot be replaced with a CA-signed certificate through normal means.

Alternative approaches:

1. Extract the AMT self-signed certificate at runtime and add it to a custom RootCAs pool for the TLS config — more secure but adds complexity.
2. Document that users must manually add the AMT self-signed certificate to their system's trusted root CA store — works but is a poor user experience and must be repeated per device.

Workaround

Users can manually add the AMT self-signed certificate to the system's trusted root CA store:

# Extract the certificate
openssl s_client -connect localhost:16993 -servername localhost < nul 2>nul | openssl x509 -outform PEM > amt_self_signed.crt

# Add to Windows trusted root store (requires admin)
certutil -addstore "Root" amt_self_signed.crt

Attachments

• Packet capture file (16993.pcapng) is available upon request.

[like-shock]

16993.pcapng.zip