Creating SSL Certificate for Vanity URL / CNAME record for ServiceNow instance

As you may be aware, ServiceNow uses as its exclusive or primary CA for issuing certs. And from what I understand, ServiceNow manages renewal of the cert. I have a Vanity URL / CNAME record pointing to a ServiceNow instance. The ServiceNow instance is The Vanity URL / CNAME record is, which is what I need to create the SSL cert for. I have control over, as it's a local web server. I can install and run Certbot off of this local web server. The problem is I don't know how to generate a signed cert for the scenario I laid out above.

ServiceNow is not listed as a LetsEncrypt hosted provider, meaning you have to upload the cert to ServiceNow. I cannot use Certbot's manual mode HTTP challenge, as I have no control of site-level folders in ServiceNow and can, therefore, not create a new web folder at the ServiceNow instance webroot.

Certbot's manual mode DNS challenge may be the way to go. I'd rather not create a TXT record, as the request to add a new DNS record may take a few days or longer to be fulfilled. I was reading up on DNS verification via a CNAME record. That sounds more appealing, to be honest. Would it have to be a brand new CNAME record or can I use CNAME as verification in order to create a cert for CNAME If yes, how?

Given the scenario above, what are my other options? Are there ACME clients which can create the cert without resorting to DNS or HTTP challenges or any DNS changes for that matter?

One other option I thought of might be point CNAME to Then run Certbot off of and create cert for Since it's all local, I won't need to use manual mode, correct? If that works, once I have the signed cert, I can point CNAME back to the ServiceNow instance and, finally, upload the cert and key store to said ServiceNow stance. And, again, ServiceNow manages cert renewals every 90 days

I'm curious to hear what are the potential solutions here.

Thank you for your help in advance.


1 Like

Assuming you are able to get a cert for the vanity name you want, are you sure ServiceNow even supports you uploading your own cert to their SaaS service?

HTTP based challenges are going to be difficult or impossible because as you know, you don't have any control over ServiceNow's web servers. I don't know if they do, but it's plausible they could explicitly support the idea of a vanity URL. They'd need you to point your DNS record to their server and then they'd take care of generating the cert on their end automatically.

It sounds like a DNS challenge will also be difficult since you don't have direct or automated control over the public DNS zone for your vanity name. I believe CNAME aliases for challenges would require using a different ACME client than certbot. You'd also need to have a public DNS zone to point to that you do have direct or automated control over (or an acme-dns instance).

You could plausibly throw a reverse proxy in front of ServiceNow's web server and terminate the SSL there (thus granting you the web server control you'd need to prove control over your vanity name). This has the advantage of leaving your vanity name in the URL bar as you're using the site (at the cost of funneling all of the ServiceNow traffic through that reverse proxy). But services behind a reverse proxy or load balancer generally need to be configured to know that they're behind it so they can adjust references to links and such on the fly. So if ServiceNow doesn't support doing that, it might not work.

The easiest thing to do would be to spin up a regular old web server with your vanity name that simply serves an HTTP 301/302 redirect to the ServiceNow site. That will definitely work with ServiceNow, but the URL bar changes to the "real" name rather than your vanity name immediately as the site loads. Whether that's a deal breaker or not is up to you.

P.S. None of these options actually involve uploading a cert you've generated to ServiceNow.


These two statements sound contradictionary to me:

Does ServiceNow use Let's Encrypt or not?

The dns-01 challenge works by prepending the label _acme-challenge in front of the hostname to be validated. This can be a CNAME, but ultimately should return a TXT RR.


ServiceNow is not a generic web hosting provider. They're a SaaS service. So they wouldn't be in the hosting provider thread. But it wouldn't surprise me in the least if they use Let's Encrypt for their certs.


There are probably tens to hundreds of hosting providers not included in the thread, so that isn't an argument to conclude the provider/service doesn't offer Let's Encrypt anyway.

1 Like

These are some great suggestions! Real good solutions. Thank you! :grinning: :pray:

Real quick: I was able to resolve the issue with ServiceNow. They took care of creating the SSL cert for the given CNAME/Vanity URL. I'll talk about that towards the bottom after I answer your questions.

Yes, ServiceNow does support uploading your own cert to the instance. The cert can be leveraged for a variety of use cases. (i.e. LDAP, mutual auth).

For further clarification, when I stated I don't see ServiceNow listed as a hosted provider, I was talking about list of the hosting providers, courtesy of Certbot;

It's possible for an entity to be both a hosting provider and a SaaS. Since I learned that ServiceNow does, in fact, create the cert on your behalf for a Vanity URL (no need for the customer to upload certs), per the definition from the aforementioned CertBot link, ServiceNow is functioning as both a hosting provider for and a SaaS platform.

ServiceNow has a module (a sub-application) called Custom URLs. The Custom URL module is where you set the CNAME/Vanity URL domain name. Once you create the record, it kicks off workflow to the ServiceNow back-end to update their Data Center and either automated workflow creates a cert or a ticket is created and a ServiceNow specialist creates the cert, binds it to the instance (well, probably a load balancer which sits at n-1 or n-2) and you're done.

Their documentation and KB was not crystal clear on who generates the cert and under what use cases and ServiceNow Support was struggling to determine that. At first, they gave me a couple of KB articles on how to create a cert and how to upload the cert to the instance. But, as I just learned, creating a cert and uploading it to the instance doesn't apply for securing a Vanity URL of a ServiceNow instance. It does, however, applies to use cases such as LDAP servers, MID servers, web services, and mutual authentication.

Again, so to doesn't get lost in the shuffle, I've learned that ServiceNow does takes care of creating the cert for Vanity URLs, on the customers behalf, and that is handled via their Custom URLs module.

Again, thank you so much for your help. Some good solutions if you-know-what hit the fan.

1 Like

As I wrote earlier, by hosting provider, I was referring to CertBot's hosting provider list. ServiceNow is not in that list. I think I may have thought the link was part of the site and, thus, figured it was implied to what I was referring. Sorry about any confusion there.

But, yes, ServiceNow uses Let's Encrypt.

If I understand it right, CNAME validation checks against _acme-challenge.CNAME and never expires and TXT validation checks against a unique value which has an expiration date and is generated by the ACME client in the TXT record. The advantage of CNAME validation is the CNAME record never expires, even for rotating keys. Does that sound about right?

Yeah, the CNAME is permanent (for varying definitions of permanent) and effectively just redirects where the TXT record must be created/updated at each renewal.


Here it sounds as you think those two things are different (CNAME / TXT), but that isn't the case. You can see a CNAME as a sort of "DNS based redirect" and it should point to a hostname containing the token in a TXT resource record. So it's a combination of both, not just one of the two.

Note that the TXT record is the ultimate record required for the dns-01 challenge and that the use of a CNAME record is optional.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.