-
Notifications
You must be signed in to change notification settings - Fork 24
Design doc for AMT WSMAN Class data fetch feature
Enable secure AMT activation on AMT 19+ without requiring insecure bypass flags,
specifically --skip-amt-cert-check.
Currently --skip-amt-cert-check skips ODCA-chain validation on the rpc-go → LMS TLS connection, and that applies in both console and cloud flows whenever that TLS leg is used.
The feature must ensure ODCA certificate chains presented by AMT are validated correctly, with clear failure behavior and minimal operational burden for customers.
| Concern | File |
|---|---|
| TLS config and peer certificate checks | internal/certs/lmsTls.go |
| Embedded trusted root loading | internal/certs/embed.go |
| Insecure bypass flag definition | internal/cli/cli.go |
| Activation path (consumes TLS config) | internal/commands/activate/local.go |
- Customers pass
--skip-amt-cert-checkduring activation on AMT 19+ platforms. - This sets
InsecureSkipVerify = trueon the TLS config, disabling all certificate chain validation against trusted roots. - The transport (mTLS) remains secure, but the ODCA chain is never verified.
Is this feature for local (console) activation only, or also for cloud (RPS/MPS) flows?
Answer: both paths are affected whenever LocalTlsEnforced is active or LMS is
present on the device. The diagrams below show exactly where each TLS hop occurs and
where ODCA verification is triggered.
The operator runs rpc activate --local directly on the managed device.
No RPS or MPS is involved.
+------------------------------------------------------------------+
| Managed Device |
| |
| +-----------+ (1) WSMAN over TLS +--------------------+ |
| | | ----------------------> | | |
| | rpc-go | localhost:16993 | LMS (Local Mgmt | |
| | (console) | <---------------------- | Service) | |
| | | ODCA cert presented | | |
| +-----------+ <-- VERIFY HERE --- +--------+-----------+ |
| | |
| (2) MEI/HECI |
| (in-kernel, no TLS) |
| | |
| +--------v-----------+ |
| | AMT firmware | |
| | (CSME) | |
| +--------------------+ |
+------------------------------------------------------------------+
| Hop | Protocol | Port | TLS? | Certificate Presented |
|---|---|---|---|---|
| rpc-go → LMS | WSMAN/TLS | 16993 | Yes | ODCA chain — verify here |
| LMS → AMT | MEI/HECI | kernel | No | — |
Code path: internal/commands/activate/local.go → SetupWsmanClient(tlsConfig)
The operator runs rpc activate -u wss://rps.example.com --profile myprofile.
RPS orchestrates activation; rpc-go relays commands between RPS and LMS/LME.
+-----------------------------------------------+
| Managed Device | +--------------------------------------+
| | | Cloud |
| +-----------+ (1) WSS (WebSocket + TLS) | | +-------------------------------+ |
| | | ----------------------------->-|--->| | RPS | |
| | rpc-go | wss://rps.example.com | | | (Remote Provisioning Server) | |
| | | <----------------------------- | | | | |
| | | provisioning commands | | +-------------------------------+ |
| | | [guarded by --skip-cert-check]| +--------------------------------------+
| | | |
| | | (2a) if LocalTlsEnforced: |
| | | WSMAN over TLS |
| | | ----------------> +----------+ |
| | | localhost:16993 | LMS | |
| | | <---------------- | | |
| | | ODCA cert +----+-----+ |
| | | <-- VERIFY HERE | |
| | | MEI/HECI |
| | | (2b) if no TLS / LMS absent: |
| | | Direct MEI/HECI (LME) |
| | | ----------------> +----------+ |
| +-----------+ (no TLS, no | AMT fw | |
| ODCA check) | (CSME) | |
| +----------+ |
+-----------------------------------------------+
| Hop | Protocol | Port | TLS? | Certificate Presented | Flag |
|---|---|---|---|---|---|
| rpc-go → RPS | WSS | 8080 | Yes | RPS server cert (standard CA) |
--skip-cert-check / -n
|
| rpc-go → LMS | WSMAN/TLS | 16993 | Only if LocalTlsEnforced
|
ODCA chain — verify here | --skip-amt-cert-check |
| rpc-go → LME | MEI/HECI | kernel | No | — | — |
Code paths:
-
internal/rps/executor.go→lm.NewLMSConnection(... skipAmtCertCheck)for LMS relay -
internal/lm/service.go→LMSConnection.Connect()dialslocalhost:16993withGetTLSConfig() - Falls back to
lm.NewLMEConnection()(direct MEI, no TLS) when LMS is absent
After activation, AMT establishes a persistent outbound connection to MPS. This is fully independent of rpc-go and has no ODCA certificate involvement.
+----------------------------------+ +-------------------------------+
| Managed Device | | Cloud |
| | | |
| +--------------------------+ | CIRA| +------------------------+ |
| | AMT firmware (CSME) | ---+---->| | MPS | |
| | | | mTLS| | (Management Presence | |
| | | <--+-----| | Server) port 4433 | |
| +--------------------------+ | | +----------+-------------+ |
| | | | |
| rpc-go NOT involved here | | +----------v-------------+ |
| | | | Management Console | |
+----------------------------------+ | | (web UI / API) | |
| +------------------------+ |
+-------------------------------+
| Hop | Protocol | Port | TLS? | Notes |
|---|---|---|---|---|
| AMT → MPS | CIRA / mTLS | 4433 | Yes | Standard server certs, not ODCA. rpc-go uninvolved. |
| Activation Path | TLS to LMS? | ODCA Check Needed? | Skipped By |
|---|---|---|---|
Console local (--local) |
Always, port 16993 | YES | --skip-amt-cert-check |
Cloud via RPS + LocalTlsEnforced=true
|
Yes, port 16993 | YES | --skip-amt-cert-check |
| Cloud via RPS, plain LMS (no TLS enforced) | Plain TCP, port 16992 | No | — |
| Cloud via RPS, LMS absent (LME fallback) | MEI/HECI kernel | No | — |
| Post-activation CIRA to MPS | mTLS, port 4433 | Not applicable (not rpc-go) | — |
The ODCA feature targets the first two rows. On AMT 19+, the ODCA root CA in those
chains changed, causing VerifyFullChain() to fail unless the correct root is in the
trust pool — hence customers resort to --skip-amt-cert-check.
rpc-go LMS (localhost:16993)
| |
|---- TLS ClientHello ---------------------->|
| |
|<--- TLS ServerHello + Certificate chain ---|
| [0] leaf: iAMT CSME IDevID RCFG |
| [1] intermediate 1 |
| [2] intermediate 2 |
| [3] ODCA ROM CA <- level 3 |
| [4] ODCA intermediate |
| [5] Intel root CA <- CHANGED on 19+ |
| |
| VerifyPeerCertificate() fires |
| in GetTLSConfig() (lmsTls.go) |
| VerifyCertificates() |
| VerifyLeafCertificate() [index 0] |
| VerifyROMODCACertificate() [index 3] |
| VerifyFullChain() |
| LoadRootCAPool() |
| needs AMT 19+ root in |
| trustedstore/ to succeed |
| |
|---- TLS Finished ------------------------->|
|---- WSMAN activation commands ------------>|
Root cause on AMT 19+: The Intel root CA at index 5 changed. If that root is absent
from trustedstore/, VerifyFullChain() fails and customers fall back to
--skip-amt-cert-check. This is what the feature must fix.
This document describes the execution flow of:
rpc diagnostics ws-man get ...
sequenceDiagram
participant U as User
participant R as WSManGetCmd.Run
participant C as resolveClasses
participant P as ensureAMTPassword
participant M as newWSMANMessages
participant F as classFetcher
participant O as renderResults
participant T as table renderer
U->>R: ws-man get -c <class> --format <fmt>
R->>C: validate class args
C-->>R: classes / error
R->>P: ensure credentials
P-->>R: ok / error
R->>M: create wsman client
M-->>R: messages / error
loop each class
R->>F: fetch data
F-->>R: data / error
end
R->>O: render by format
alt format == table
O->>T: extractClassInstances
T->>T: parse raw XMLOutput if present
T-->>O: Name/Value table
end
O-->>R: rendered bytes
R-->>U: stdout or output file
Explore and compare how trust anchors are supplied.
| Option | Description |
|---|---|
| 1 | System trust only (OS trust store) |
| 2 | Embedded trust only (compiled into binary via trustedstore/) |
| 3 | Combined trust — system + embedded |
| 4 | Custom trust path configured by the customer at runtime |
Questions to answer:
- Which option works reliably on Linux and Windows deployment patterns?
- Which option minimizes customer setup effort?
- Which option is easiest to maintain when ODCA roots are updated?
Explore chain building and validation logic in detail.
- Correct chain building from AMT leaf → intermediates → ODCA root
- Behavior when the chain is partial or contains unexpected certificates
- Behavior when AMT cert hash and the presented leaf certificate do not match
- Behavior during AMT control mode transitions mid-activation
Questions to answer:
- What is the canonical expected chain length and which variants are acceptable?
- Which checks should be hard failures vs. logged warnings?
- How should errors be surfaced to the user so they can remediate?
Explore how customers obtain, provide, and maintain trust material.
- Manual OS trust store management (IT-administered)
- Embedded roots shipped in the binary (product-managed lifecycle)
- Optional bootstrap command to install or validate trust material
Questions to answer:
- Who owns root updates — the customer, the product release, or both?
- Is there a secure update process for embedded roots between releases?
- What documentation is required for enterprise rollout?
-
ensureAMTPassword(ctx)is required so WS-Man requests have credentials. It is fetched using GetLocalSystemAccount(). - In multi-class mode, a single class fetch failure does not stop the whole command.
-
--format tableis XML-driven and prefers rawXMLOutputso zero/false/empty fields are preserved. This is mainly for user to get only the meaningful data. -
--format jsonand--format xmlkeep their existing serialization behavior.
internal/commands/diagnostics/wsman.go