No, a public CA signed certificate is not required for PnP or any other feature/function of DNAC as far as I'm aware. As stated by @bradwilson75, at the start of the pnp process the pnp agent downloads the root certificate in the DNAC signed certificate chain (downloads from DNAC) and installs it as a temporary trustpoint that is then used for cert validation.
I agree that Cisco's docs are a little confusing as the Security Best Practices guide states 'Replace the self-signed server certificate from Cisco DNA Center with one signed by a well-known certificate authority (CA)', however in reality this cannot be a public CA as they will not accept a certificate signing request that includes private IP addresses. Internal Microsoft signed certificates have worked well for me so far.
Also regarding LAN automation and standard PnP, I was just trying to find a way of wording the difference between LAN automation that is used to provision the routed underlay on new devices in preparation for SD-Access (using an inbuilt template that cannot be customised) and non-LAN automation PnP which is used to provision new devices with a customised configuration (that the administrator defines using the template editor). Both are forms of PnP/day-zero provisioning if that makes sense.
With LAN automation, DNAC provisions a temporary DHCP pool on a 'seed switch' that is used to allow connected devices to discover DNAC. This auto provisioned DHCP pool uses option 43 with IP for DNAC discovery which is why the IP address must be in the certificate SAN
For standard/non-LAN automation PnP, you have a number of options to enable a device to discover DNAC such as DHCP with option 43 IP (again IP must be in the certificate SAN for this to work) or DHCP with DNS based discovery, which by excluding option 43, forces the device to perform a DNS lookup on pnpserver.localdomain. For DNS based discovery, the pnpserver.localdomain FQDN must be present in the certificate SAN.
As you may need to do both in a single DNAC deployment, you will need include both the IP addresses and pnpserver.localdomain in the certificate SAN
Hope this helps
EDIT
Correction on the above regarding cert validation. I have researched and the pnp agent actually downloads a Trustpool bundle from DNAC (found under System Settings -> Settings -> Trustpool) which contains a number of Cisco and third party root certificates. You will see this in the PnP logs
%PKI-6-TRUSTPOOL_DOWNLOAD_SUCCESS: Trustpool Download is successful
The following explains the purpose of the Trustpool bundle:
"DNA Center supports the import and storage of a PKI trustpool bundle from the Cisco cloud. This PKI trustpool bundle enables supported Cisco networking devices to authenticate the controller and its applications such as Network Plug and Play, upon the presentation of a valid third-party vendor issued certificate.Cisco DNA Center already contains a pre-installed PKI trustpool bundle. This is an ios.p7b file that only supported Cisco networking devices can unbundle and use"
I have checked and the chain that is used to sign the DNAC certificate is also included in this Trustpool bundle (in my case, this includes the Microsoft CA chain that I uploaded to DNAC during the cert replacement process). As the bundle also includes public CA cert chains, such as for GoDaddy, Entrust etc. it would suggest that the DNAC cert could be signed by a public CA, however as outlined in my previous posts, I dont see how this is possible if private IP addresses are required in the SAN. Cisco may need to comment on this.
Sorry for the long post, but I think that this has helped make more sense of the PnP cert validation process for myself as well :-)
