Hi Zip,
By "the server's hostname" I assume you mean the hostname configured on the Assurance server, and "the server's DNS name" is the A record for the DNS record of the DNS zone which is being used for the IP lookup.
Although the hostname should be within the DNS zone file, assuming it's enrolled in that domain and DDNS is in play, it's possible to have multiple aliases for any particular A record. So peterparker can be an alias for spiderman, and they can both be in the DNS server's zone file.
The thing to remember about SSL/TLS is that during the handshake between client and server, the DNS A record and server hostname don't matter. It's the content of the public keys which are important. Specifically the CN and Issued fields.
The client receives the public key from the server and if the CN field doesn't match the URL, you'll receive a warning which you can choose to accept and continue. For example, you enter the URL:
"https://spiderman". If the server's public key states that the CN is "spiderman.mydomain.dom" rather than "spiderman" then you'll get a warning. Otherwise, it's fine. You can also have multiple CN's within a key, by putting alternative names for the server under the SAN field (subject alternative name). So technically you have a single CN, and zero or more SANs.
If you create your own self-signed key for the server, instead of issuing it from a trusted publisher which both your client and server trust, then you'll always get a java security warning since the client doesn't trust the server's issuer. In that case just connect to the server via the DNS A record ("Spiderman"). The hostname doesn't matter.
Also, if you make your own key then be sure to update the config file under the tomcat directory in your Oneclick server.
Check out this link for more: https://docops.ca.com/ca-spectrum/9-4-1-to-9-4-4/en/administrating/oneclick-administration/oneclick-server-communications-and-network-configuration/configure-oneclick-for-secure-sockets-layer/