Wildcard certificates

You can use wildcard TLS certificates for your MDM Server in several scenarios.

For example:

  • when your MDM server is configured in cloud infrastructure where a load balancer terminates TLS.
  • when your MDM Server is terminating TLS from devices on the Internet through a firewall hole.

In these cases, you can obtain a wildcard certificate from your Trusted CA of choice (example of the form “*.test.bigfix.com”) instead of a specific FQDN like “mdm.test.bigfix.com”.

Having a wildcard certificate allows separate servers in the domain to be able to share the same TLS certificate. For example, you can have two separate MDM servers: mdm1.test.bigfix.com and mdm2.test.bigfix.com, and both can be handled through the same wildcard certificate.

With whichever option you use, the wildcard certificate must be configured on the server that is actually terminating TLS from MDM enrolling devices.

  • In cloud infrastructure, this would likely be a front-end load balancer which terminates TLS and routes connections to a cloud-based MDM Server VM. This load balancer will likely have a cloud-specific FQDN by default, so a CNAME must be defined in your DNS server to route your devices to correct TLS termination point using the desired FQDN. For example, entering a URL of https://mdm.test.bigfix.com would resolve to a load balancer which could have a name like “mdm-test.bigfix-com-1216115951.eu-central-1.elb.amazonaws.com”.
  • For a standard on-premises solution where the MDM server is running in the DMZ and there is a firewall hole to let port 443 traffic in to reach the MDM server, the MDM server must be set to use the wildcard certificate.
Just as with a dedicated certificate specifying the FQDN of a specific server, you must provide the certificate chain and not just the individual TLS certificate when supplying the wildcard certificate. Example:
  • *.test.bigfix.com
  • Intermediate CA supplied by the Trusted CA
  • Root CA supplied by the Trusted CA