How do I troubleshoot SSL certificate issues?
All supported versions
Sites that use custom domain SSL
We are experiencing issues with our SSL certificate on our end-user pages.
When a client has a SSL certificate for a custom domain and it begins experiencing issues, it is usually caused by the same handful of common scenarios. As with most troubleshooting scenarios, it is best to check the most basic elements first, and then move on to more complex methods if necessary.
Every SSL certificate on the web has a scheduled expiration date. The cert authority you buy from will offer a variety of options for validation periods when issuing the cert. The validation period you choose is not a concern to Oracle, so you can choose whichever option works best for your organization.
Usually certs are valid anywhere from 1-2 years. 3 year certs are becoming less common but may be an option at certain providers. If a certificate expires it will continue to be served on the end-user pages, but will not be valid and will issue a warning to anyone who tries to access using the HTTPS/SSL protocol. The only fix in this scenario is to provide a replacement cert with valid dates as quickly as you can.
With certificate renewals, you are able to use the same CSR (Certificate Signing Request) you used to purchase the certificate originally, year after year. The only reason this would change is if you needed to make an adjustment to the content of the CSR's fields, such as changing your listed Organization name, for example. It is preferred to reuse the same CSR whenever practical. This also helps to simplify the cert management process.
No DNS CNAME Entry:
A necessary part of the custom domain process with OSvC is the association of the new custom domain to the original custhelp.com version of the interface address, which is done through DNS, and specifically through a CNAME record. Without a CNAME record, there is no way to associate the custom domain to the OSvC interface, and therefore a significant site down scenario can occur if not configured properly. Our self-service system in Configuration Assistant will stop a vhost name change if no CNAME record is present, to prevent damage to the site.
If you try to access your end-user pages to test and find that the page is completely unable to load, or suggests an issue in resolving the hostname, the issue is very likely to be CNAME related.
To verify that a CNAME is in place, you can use a Dig query. Dig can also run natively from a terminal in Linux, but the easiest way if using Windows is to use free tools offered on the web. Google's DNS is one of the most reliable tests of the site's readiness on the Internet, and their Dig tool can be found here:
Our CX support site employs this same process and can be used as an example. If you run a Dig query for cx.rightnow.com, you will see that it points the custom vhost to the original rightnow.custhelp.com, like so:
id 19958 opcode QUERY rcode NOERROR flags QR RD RA ;QUESTION cx.rightnow.com. IN CNAME ;ANSWER cx.rightnow.com. 899 IN CNAME rightnow.custhelp.com. ;AUTHORITY ;ADDITIONAL
The vhost is not behaving as expected (What does vhost even mean?)
The vhost is just another name for the virtual host, or hostname of the site. Every interface must have a minimum of at least one primary vhost, but can have a theoretically unlimited number of alternate vhosts. No matter what, the primary vhost is the address that is displayed in the browser once the page loads, and alternates are used for redirection to the primary only..
Using our support site as an example, cx.rightnow.com has been made the primary vhost for the rightnow interface. The alternate vhost is rightnow.custhelp.com. This means that anyone who types rightnow.custhelp.com into a browser will be automatically redirected to cx.rightnow.com. The purpose of this primary/alternate design is to designate a final landing page as served from Oracle's side.
Occasionally clients will ask if it is possible to have two unique landing page URLs shown in the browser. This is unfortunately not an option. In all circumstances, the primary vhost is what is shown in the browser's address bar once the page is up, and alternates perform redirection to the primary.
The vhost that is in place for an interface doesn't inherently care about SSL, or a valid certificate. A vhost configuration could in theory be changed at any time, but if there is not a certificate in place to cover the custom domain, anyone who tries to access the site using HTTPS will encounter an error. For this reason, in most scenarios we avoid changing the vhost at all unless there is a valid certificate to cover the name. This is even more important now, as most major browsers are phasing out of using 80/HTTP altogether.
How certificates are served on your end-user pages, from the Oracle hosting perspective:
When your site is first provisioned with us, interfaces are added to our *.custhelp.com domain on our wildcard certificate. This custhelp.com wildcard cert is served on the VIP, or server, that hosts the site. The VIP is simply a virtual IP address that answers requests to the page, but is actually a collection of devices in the data center operating in a cluster.
When a client wants to use a custom domain, in our server cluster we create a new VIP that serves your certificate only. This borrows from IP space that is dedicated at the pods for this purpose. If a VIP is created to serve a certificate, then all interface names that are covered on that certificate are moved off the custhelp.com VIP, to the new VIP..
For example, if you provide us with a cert that has coverage for three of your interfaces, then these three interfaces will be moved to the newly created VIP that serves this certificate, resulting in an underlying IP address change. Similarly, if you have a wildcard cert and it is able to cover all your interfaces within the proper name format, then all of the desired interfaces can be covered will be moved to this VIP, and so on.
Verifying a certificate's compatibility:
In order for your certificate to work in our environment, the certificate must be purchased from a CSR that came from us originally. This is because when a CSR is created, there is also a private key that is generated and stored hidden in our servers. This private key is what is used to encrypt the traffic, and must be present in our environment for the certificate to work. Thus, you cannot generate a CSR elsewhere and then bring it to Oracle for installation. Attempting to do so will cause errors in self-service.
If you happen to have a large number of certificates to manage for your organization, you may occasionally find that the CSR and corresponding certs get mixed up accidentally. To verify that the CSR is a correct match to the cert, you can use the free tools at sslshopper.com:
When the page loads, change the radio button to 'Check if a CSR and certificate match'.
From here, paste the CSR output into the text box. To get the certificate output, you can right-click on the cert file and open it with a text editor. At this point, you should have both the CSR and cert, and can paste them into the boxes. If everything checks out with matching hashes, it will present a clear notice saying that they are matched. The modulus values must be identical in order for the cert to work.
For any other issues that appear to be certificate related and are not mentioned above, you can submit a service request to Technical Support for additional assistance.