How do you feel when you got to know that you cannot use SSL of your own choice for your domain rather you would need to use some specific company SSL ???

Wait… WHAT? Why would I use SSL of someone else choice…

Recently I’ve been landed in the similar situation when I learnt about it during the implementation of custom URL for ServiceNow instance that I’m bounded to leverage Lets Encrypt SSL certificate.

ServiceNow has been offering custom URL functionality since long and I recommend it over instance Renaming, now, you would think what is instance Renaming? Let’s take a step back and learn about custom URL and instance renaming in details.

Being a platform custodian you manage 3 SN instances DEV, UAT, & PROD and their corresponding URLs would be abcdev.service-now.com (DEV), abcuat.service-now.com(UAT), & abc.service-now.com(PROD) respectively*.*

Regular domains are your standard SN URLs like service-now.com.

Subdomains are a unique SN URL that lives on your purchased domain as an extension in front of your regular domain like abc.service-now.com.

Recently, your company branding guidelines have changed and customer has asked you to explore the ways of updating the SN instance URLs as per new guidelines.

Being custodian, you have 2 options Instance Renaming and Custom URL, when regular domain is unchanged and subdomain is changed, you can call it as Instance Renaming, to do the renaming you need to raise ticket in Hi Portal and risk involve is higher in renaming & there is downtime of 20 mins. Renaming e.g., current URL is abc.service-now.com and post renaming it will become xyz.service-now.com.

Custom URL, when both domain and sub-domain are changed, e.g., current URL is abc.service-now.com and post custom URL it will become xyz.abccompany.com. Low to minimal risk is involved and there is no downtime. A custom URL should activate within six hours on your instance. A background job polls for custom URL job completion every 30 mins.

Even with all the pros there is one disadvantage that might push you to not to go for custom URL i.e., no custom SSL!!!

Let’s Encrypt certificate authority CLS

By the time I gotta learnt about it, I’ve reached out to HI and they suggested that prior Tokyo it would not be feasible to use your own SSL, however, with Tokyo release SN has introduced the Infrastructure Security plugin, below are the steps to enable/sign your own SSL certificate (SYOC):

1. Install the ServiceNow Infrastructure Security Settings (com.glide.infrastructure_security) plugin

2. After installing the plugin, enable Sign Your Own Security (SYOC) functionality by setting the sn_infra_sec.syoc.enabled system property to true

sn_infra_sec.syoc.enabled property

3. Generate and upload your own certificates, which can be signed by the certificate authority of your choice. Then, you can use the tools to upload the signed certificate to your instance’s load balancer.

— Within instance go to Generate CSR module, you would find 3 sections Domains, Optional Certificate Fields & Generated CSR, however Generated CSR will be visible once when you submit by filling details in other 2 sections.

Congratulations, you have successfully generated the CSR for custom domain, inspite of generating the CSR you are halfway in your journey of custom SSL.

You would need to securely purchase the dedicated SSL for every ServiceNow instance. You might be wondering, I have multi-domain certificate why do I need purchase SSL certificate for every instance, can’t I use the SAN certificate?

What is SAN certificate? so, if you possessing the knowledge of networks and domain then you would be knowing that it is digital security certificate which allows multiple hostnames to be leveraged by single certificate.

Long story short, SAN is the multi-domain certificate, unfortunately ServiceNow does not support SAN certificate in their current architecture, nevertheless, ServiceNow allows you to load the dedicated SSL certificate & root chain to enable the custom URL for your instance.

So far, plugin has been enabled, property has been set to true and CSR has been generated and SSL has been secured successfully, but how and where will I load the custom SSL certificate within instance?

Not to worry, just search for Upload Certificate module under Infrastructure Security in application navigator as shown in below snippet

Post uploading the SSL, root certificate and intermediate certificate correctly, you would see the successful info message and SYOC setting module would show all the active certificates like shown below

Congratulations !!! you have successfully uploaded your custom SSL and it is attached to you instance. Now, you can need to create the custom URL record and post completion of DC job, your custom URL record will be set Active and your custom SSL is attached & working with custom URL.

Top take-aways:

• Infrastructure Security plugin is free to use however you would need to purchase the SSL for your instance, so, if you own 3 instances which means you need to purchase 3 SSLs
• Before creating custom url record custom SSL has to be uploaded first otherwise custom ssl can’t be uploaded after creation of custom url because DC jobs may conflict
• SAN is not supported in current architecture

Prior implementing custom URL, my mind was filled with lots of questions/concerns and thanks to Casey Barela, we both share the Dev MVP cohort and after having detailed discussion with him, I have become positive to go for Custom URL.

Bonus Tip: If you ending-up with the below errors even after following all the steps:

- Multiple DC jobs created for single custom URL record, you’d need to delete the incomplete job, however to do so, you first update the ACL as Admin/Maint roles do have privileges to delete the DC jobs, it requires ‘nobody’ role

- Record delete operation that requires a Role ‘nobody’ with description:

The “nobody” role means that nobody has access — not even Admin or Maint. Warning: Applying the nobody role may be irreversible if applied to some important system functions.