Intel AMT Certificate with different FQDN and server hostname

[PiotrTSii]

Hi

I have installed the Intel EMA server. All components are on a single machine that is part of Active Directory. The FQDN I configured and exposed to the internet is

ema.domain.pl

and the name of this machine in Active Directory is

hostname.example.pl

I am applying for a certificate in IIS(from GoDaddy), and I need to specify the Common Name (CN). Which one should I use — the FQDN that is exposed externally? I intend to use this value on the client machines in Intel MEBX. 

Maybe I should use wildcard certificate abd Which provider would be suitable for an AMT PKI wildcard certificate?

Regards

Peter

[Arun_Intel1 · Accepted solution]

Hi PiotrTSii,

Greetings!

You should use the externally exposed FQDN (ema.domain.pl) as the Common Name (CN) when applying for your GoDaddy certificate in IIS, since this is the address that client machines, including those using Intel MEBX, will use to connect to your Intel EMA server.

Intel’s updated guidance for EMA (not the older SCS tool) clarifies that the certificate should be created under a public domain name, and the CN should match the FQDN that is resolvable and accessible by your endpoints. Using the internal Active Directory name (hostname.example.pl) as the CN would result in certificate mismatches and connection errors for clients connecting via the public FQDN.

Therefore please specify ema.domain.pl as the CN for your SSL certificate application. This ensures that all client devices connecting to Intel EMA over the internet will trust the certificate and establish secure connections without errors.

We would request you to purchase a GoDaddy certificate as you have suggested, you may purchase an AMT provisioning certificate with the OID  2.16.840.1.113741.1.2.3, for provisioning the endpoint with the Intel EMA console in Admin Control Mode (ACM).

Intel® AMT Admin Control Mode (ACM) provisioning requires a certificate issued by a trusted authority that matches the domain name of the target Intel AMT endpoints.
The certificate file needs to have the full certificate chain. Also, it needs to be issued with the supported OID 2.16.840.1.113741.1.2.3 (this is the unique Intel AMT OID)

Best Regards

Arun_intel

[Jimmy_Wai_Intel]

A little bit of correction here. CN in the certificate should match DHCP Option 15 on the network the PCs are connected to, or the PKI DNS suffix in MEBx. If you choose to use DHCP Option 15, you can find out the value of Option 15 by running IPCONFIG /ALL and look for the value of Connection-specific DNS Suffix under the active ethernet connection. If you choose to enter PKI DNS suffix in MEBx manually, you need to purchase a certificate that matches the suffix.

For more details about the verification between CN and DHCP Option 15 or PKI DNS suffix, you can refer to the following page in the Intel AMT Reference Guide.

Intel® AMT SDK Implementation and Reference Guide

Regards,

Jimmy Wai

Technical Sales Specialist, Intel

[PiotrTSii]

Hi Arun_intel and Jimmy Wai

Thanks for your response.

I would appreciate your input regarding the correct setup and best practices for Intel AMT remote configuration in our specific environment.

My current scenario:

1. All Intel AMT components (RCS, provisioning server, etc.) are installed on a single on-premises server.
2. We have an on-premises Active Directory domain: abc.com, but the user UPN suffix is xyz.com.
3. The namespace xyz.com is publicly available and resolvable from the internet.

My questions:

1. What is the recommended way to expose the AMT configuration server to the internet?
   Should we use traditional NAT or would a load balancer (e.g. KEMP) be more appropriate? Are there any constraints or recommendations when using a load balancer in front of the AMT provisioning server?
2. Given the internal domain (abc.com) differs from the external one (xyz.com),
   is it necessary to use a multi-domain SSL certificate on the provisioning server (e.g. provisioning.abc.com and provisioning.xyz.com) to ensure compatibility with the Intel AMT PKI trust model?
3. Since about 90% of our endpoints are outside the corporate network,
   what is the most efficient way to deploy Intel vPro with AMT in such a distributed environment?
• Do we need to manually enable AMT on each device (e.g. via MEBx or BIOS)?
• Or is there a scalable method for activating AMT remotely on offsite devices?
• Also, since the majority of devices are not inside the corporate network, it seems that DHCP Option 15 is not applicable in this case — would you confirm?
• Considering the following guidelines from the screenshot, I understand that in addition to entering the PKI DNS suffix in MEBx, I also need to enter the SCA FQDN in MEBx(DHCP Option 15 is not applicable) could you please confirm this?

[Arun_Intel1]

Hi PiotrTSii,

1.Recommended Way to Expose the AMT Configuration Server to the Internet

Best Practice:

Intel recommends placing the AMT configuration server (e.g., Intel EMA Swarm server, RCS, or MPS) behind a secure gateway, such as a reverse proxy or load balancer, in a DMZ. This setup allows you to control, monitor, and secure inbound and outbound traffic between external endpoints and your internal provisioning infrastructure.

Options:

Traditional NAT:

You can use NAT to forward external requests to your internal server, but this offers limited traffic management and security features.

Load Balancer (Recommended):

Using a load balancer (such as KEMP) is preferred for production environments.

Constraints/Recommendations with Load Balancer:

Ensure the load balancer supports TCP pass-through for AMT protocols, especially if using non-HTTP protocols (e.g., redirection, SOL, IDE-R).

Configure SSL certificates on the load balancer or ensure it can forward SSL traffic without terminating if end-to-end encryption is required.

Open only the necessary ports (commonly 16993, 16995 for TLS-based AMT management, or your custom EMA ports).

Place the load balancer in a DMZ and restrict access with firewall rules.

2. SSL Certificate: Multi-Domain Requirement?

Scenario:

Internal AD domain: abc.com

User UPN suffix and public namespace: xyz.com

Intel AMT PKI Trust Model:

Intel AMT firmware validates the provisioning server’s certificate against the PKI DNS suffix entered in MEBx or set via profile. The certificate’s CN or SAN must match the FQDN that AMT clients use to connect.

Recommendation:

If all endpoints (internal and external) use provisioning.xyz.com (publicly resolvable) to reach the server, you only need a certificate for provisioning.xyz.com.

If some endpoints use provisioning.abc.com (internal) and others use provisioning.xyz.com (external), a multi-domain (SAN) certificate covering both FQDNs is required for seamless provisioning and management.

The certificate must be from a CA trusted by Intel AMT (public CA or an internal CA whose root is loaded into the AMT firmware).

3. Efficient Deployment for Mostly Offsite Endpoints

Manual Activation:

Traditionally, AMT must be enabled in the MEBx (BIOS) interface, which often requires physical access for initial setup.

For remote, distributed environments, this is not scalable.

Scalable/Automated Methods:

Remote Configuration (PKI):

If your endpoints ship with AMT in "factory default" mode and you have a valid PKI infrastructure, you can use remote configuration. This requires:

The correct PKI DNS suffix in MEBx (often pre-configured by OEMs for public CAs).

Endpoints able to reach the provisioning server over the internet (using the public FQDN and certificate).

No need for DHCP Option 15 if endpoints are outside the corporate network.

OEM Pre-Configuration:

Work with your hardware vendor to pre-configure AMT settings and PKI DNS suffixes at the factory, minimizing manual touch.

Provisioning Agent:

Use Intel EMA’s agent-based provisioning, where the agent runs on the OS and initiates AMT activation remotely, provided the OS is running and has network access.

4. DHCP Option 15 Applicability

Correct: DHCP Option 15 (DNS domain suffix) is not applicable for endpoints outside your corporate network or not using your internal DHCP.

For remote endpoints, you must manually set the PKI DNS suffix in MEBx or ensure it is pre-set by the OEM. This suffix must match the domain on the provisioning server’s certificate.

5. Entering PKI DNS Suffix and SCA FQDN in MEBx

Correct: For remote provisioning, you must enter:

The PKI DNS suffix (matching your public domain, e.g., xyz.com) in MEBx.

The SCA (Setup and Configuration Application) FQDN (e.g., provisioning.xyz.com) in MEBx or via the provisioning profile.

This ensures the AMT device trusts the provisioning server’s certificate and can establish a secure connection.

Best Regards

Arun_intel

[Arun_Intel1]

Hi PiotrTSii,

Greetings!

Please feel free to revert for any further query!

Best Regards

arun_intel

[PiotrTSii]

Hi Arun_intel

Thank you for your detailed and professional response — it really helped me solve the issue. Much appreciated!

Best Regards

PiotrTSii

[Arun_Intel1]

Hi PiotrTSii,

Glad to hear that the issue has been resolved! We shall proceed with the case closure.

Best Regards

arun_intel