If you want your website to be accessible securely then you need to have an SSL certificate that your web browser can use to confirm the site is genuinely who it claims to be. With this certificate, the website can be accessed via https instead of http.
Our cloud provider, Amazon Web Services (AWS), can create and manage these SSL certificates for us, but they, of course, need to be authorised to do so (you wouldn’t want just anybody to be able to create and manage certificates for your domain). The way they do this is to prove that you control the domain that you want the certificate for. This is done through the creation of DNS entries.
Why we ask you to create a DNS entry
When we tell AWS that we want a certificate for the domain *.example.com they will ask us to create a DNS entry for a specific domain with a long unguessable name. This might be something like _4aa3930127e6ca09111afd3b112f3c67.example.com. This DNS entry will be a CNAME pointing at a non-existent domain name such as _5f306a634c85653061c280155801050c.acm-validations.aws.
Only you will be able to create DNS entries for your domain, so nobody except you will be able to provide AWS with this authorisation.
Once you have created the appropriate DNS record then AWS will detect this and create the requested certificate. This authorisation is ongoing as well, which means that when the certificate is due for renewal after a year, AWS will do it automatically without you having to do it yourself.
Wildcard vs non-wildcard certificates
You will notice in the above example, the certificate was described as for *.example.com. If you are not aware, the ‘*’ means that any word can be substituted for the asterisk. So this wildcard certificate will work for insights.example.com, thoughtleadership.example.com, passle.example.com, or anything else you might want. This means that if you add a new Passle or decide you want to change the domain that your existing Passle is on, then the certificate will still work fine.
The other alternative is to have a non-wildcard certificate. In this case, the certificate would be for your specific current domain name such as insights.example.com. This will work fine up until the time you get a second Passle.
If you wanted to have a second Passle at thoughtleaderships.example.com, then we would have to go through this process again: we would need to provide you with a new DNS entry to set up, and so on. Likewise, if you wanted to change from insights.example.com to experts.example.com then we would also need to go through the process again.
So should I have a wildcard or a non-wildcard certificate?
This is entirely up to you! A wildcard certificate as described above is a lot simpler in virtually every way. There is nothing for you to do if you want to make the sorts of changes mentioned above: you just set it up once and then never worry about it again.
So why wouldn’t I choose a wildcard domain?
Some people may be concerned because a certificate for *.example.com would in theory work for www.example.com. There isn’t anything we could do with this information of course. www.example.com wouldn’t be pointing at our web servers so there would be no opportunity for us to pretend to be www.example.com with this certificate.
Some companies may have policies in place however, that state that a wildcard certificate shouldn’t be created (that is, if you don’t need a wildcard domain then you shouldn’t have one). This is of course perfectly OK with us. There may be a little more back and forth needed when making changes, but we are happy to do that to comply with your requirements.