There is a change in the behavior of the 2.1.21 cadi-aaf agent with a wildcard cm domain FQDNs/machinename argument. In earlier release, the FQDNs/machinename argument was of the form:

   *.domain:machinehostname.domain:SAN-fqdn1:SAND-fqdn2:…

and the values of the FQDNs were sent in the ‘PUT /cert/aaf?withTrust’ body mostly unchanged, e.g., an FQDNs argument of:

   *.team.corp.com:hello-world-azure-dev00.team.corp.com:tls-app-service.default.svc.cluster.local

Would result in a ‘PUT cert’ body of (pretty-printed):

{{{}}
   "mechid": "m12345@certid.dev.controller.team.corp.com",
   "sponsor": "xxxxx@corp.com",
   "fqdns": [
     "*.team.corp.com",
     "hello-world-azure-dev00.team.corp.com",
     "tls-app-service.default.svc.cluster.local"
   ]
}

But with the 2.1.21 client, the same command-line would result in a ‘PUT cert’ body with the wildcard template machine name in the second position of the fqdns array, instead of the first position:

{{{}}
   "mechid": "m12345@certid.dev.controller.team.corp.com",
   "sponsor": "xxxxx@corp.com",
   "fqdns": [
     "hello-world-azure-dev00.team.corp.com",
     "*.team.corp.com",
     "tls-app-service.default.svc.cluster.local"
   ]
}

Which causes the server to emit a error like:

SVC1406 Not Acceptable: There is no DNS lookup for *.team.corp.com

FYI: After staring at the server code for a while, I felt an impulse to try a work-around of placing two instances of the wild-card template domain name at the beginning of the FQDNs argument given to the cadi-aaf agent, and this generates a pair of consistent ‘GET cert/artifact’ and ‘PUT cert’ requests. Note that other than probably breaking Agent.java line 805 (I have no clue what that is supposed to do) it generally seems to work.