1 of 1 people found this helpful
The .local is not on our Top Level Domain list, therefore, the configuration certificate will need to also match the dev label.
For support of clients in bamits.local and dev.bamits.local your options are 2 standard certs for each domain, a multi-domain certificate that includes the two domains, or a wild card certificate.
What does this mean?
Top Level Domain AMT support list:
.EDU .GOV .ORG .BG .CH .CL
.CZ .DE .DK .COM .NET
.ARPA .AR .AT .BE .BR .CA
.CN .CO .EE .ES .FI .FR
.GR .HK .HR .HU .IE .IL
.IN .LT .MX .NL .NO .NZ
.PL .PT .RO .RU .SE .SG
.TH .TR .TW .UA .UK .ZA
Customers owning a DNS under domains on this list can utilize a single standard SSL certificate to provision the entire vPro fleet including all sub-domains in their organization (Intel Advanced Management Technology firmware will treat this certificate as a wildcard certificate)
In other words, if the domain is not on this list the customer would have to resort to Wildcard or Multi-Domain certificates to cover all existing sub-domains to be able to provision AMT in each one.
Example of a domain not on the list:
A Standard SSL certificate for domain “bamits.local” will only support AMT clients in this domain to configure. AMT clients in “dev.bamits.local” or “test.bamits.local” for example will be rejected. This would work with a wildcard cert of “ *.bamits.local” or multiple domain certificates.
You have explained it very well.