Outbound SSL and TLS connectivity from ServiceNow InstanceWhat is SSL used for ? The SSL and TLS protocols enable two parties to identify and authenticate each other and communicate with confidentiality and data integrity. The TLS protocol evolved from the Netscape SSL 3.0 protocol but TLS and SSL do not interoperate. The SSL and TLS protocols provide communications security over the internet, and allow client/server applications to communicate in a way that is confidential and reliable. The protocols have two layers: a Record Protocol and a Handshake Protocol, and these are layered above a transport protocol such as TCP/IP. They both use asymmetric and symmetric cryptography techniques. An SSL or TLS connection is initiated by an application, which becomes the SSL or TLS client. The application which receives the connection becomes the SSL or TLS server. Every new session begins with a handshake, as defined by the SSL or TLS protocols. Uses for SSL and TLS include : HTTPS, FTPS, SOAP, REST, SMTP, IMAPS and many other services rely on transport layer security. The rule of thumb is: if you need a secure connection, you probably need a certificate. Difference between SSL and TLS SSL is the predecessor to TLS. SSL was released in different versions, there was no version 1. There is SSLv2 and SSLv3. TLS was introduced in 1999 as a new version of SSL and was based on SSL 3.0. Both SSL 2.0 and 3.0 have been deprecated by the IETF (in 2011 and 2015, respectively). Certificates are NOT dependent on SSL/TLS Protocol TLS Flow Below are the steps taken by the Client (application that is connecting) and Server (application receiving the connection) The client sends a "Client hello" message to the server, along with the client's random value and supported cipher suites.The server responds by sending a "Server hello" message to the client, along with the server's random value.The server sends its certificate to the client for authentication and may request a certificate from the client. The server sends the "Server hello done" message.If the server has requested a certificate from the client, the client sends it.The client creates a random Pre-Master Secret and encrypts it with the public key from the server's certificate, sending the encrypted Pre-Master Secret to the server.The server receives the Pre-Master Secret. The server and client each generate the Master Secret and session keys based on the Pre-Master Secret.The client sends "Change cipher spec" notification to server to indicate that the client will start using the new session keys for hashing and encrypting messages. Client also sends "Client finished" message.Server receives "Change cipher spec" and switches its record layer security state to symmetric encryption using the session keys. Server sends "Server finished" message to the client.Client and server can now exchange application data over the secured channel they have established. All messages sent from client to server and from server to client are encrypted using session key. TLS Flow Simplified Flow Below Parts of TLS Technically, TLS consists of two parts: The TLS handshake layer manages which cipher (the type of encryption algorithm) will be used, the authentication (using a certificate specific to your domain name and organization), and the key exchange (based on the public-private key pair from the certificate). The handshake process is performed only once to establish a secure network connection for both parties.The TLS record layer gets data from the user applications, encrypts it, fragments it to an appropriate size (as determined by the cipher), and sends it to the network transport layer. Gathering Data for you Case Connecting to an endpoint using TLS is dependent on many things on the client side. For example if using a Browser, the browser is in charge of making the connection and exchanging certificates. if the Client is using a Web Proxy, this also affects how the connection is made. It is important to Narrow down and isolate an issue when you have a Case. Some tools and things you can use to test: OpenSSL : This is a command line tool in Linux and MAC. This allows you to connect to an endpoint and negotiate an SSL connection, this command lets you print lots of certificate and SSL negotiation information during the connection. Below are the commands you can use to test a connection : openssl s_client -connect hi.service-now.com:443 This command will attempt to create an SSL connection to hi.service-now.com. It will print out the connection details and certificates presented by hi.service-now.com, and other info as mentioned below. Its important to try this as this connection from the command line is independent of our software. If any errors are encountered by this command they are printed in the output. This should always be added as a worknote in your case. openssl s_client -connect hi.service-now.com:443 | openssl x509 -noout -text This is similar to the previous command, but instead it will give you detailed information on the Certificate received from the server including SAN (Subject Alternat Name) info, OCSP info, and other signing info What can affect a successful connection There are many factors that can affect a succesful connection. Only some of these are listed below: OCSP OCSP stands for Online Certificate Status Protocol. The theory behind it is that a company creates a Certificate and gets it signed. If for security reasons they want to update the certificate on their server but they want people using the old certificate to know that the old Cert is no longer available. They use OCSP. OCSP is an extra check done by the client (if they are a good client). In OCSP, the Certificate Authority (CA) e.g. Entrust owns a Certificate Revocation List (CRL). This is a list of Certificates that are not valid anymore and should not be used. When a Client e.g. ServiceNow connects to a server, during the SSL handshake the endpoint will tell us who owns its CRL. to see this you can run : openssl s_client -connect hi.service-now.com:443 | openssl x509 -noout -text In the result you will see a section like this : Authority Information Access: OCSP - URI:http://ocsp.entrust.net CA Issuers - URI:http://aia.entrust.net/l1k-chain256.cer You can see above thet Entrust owns the Certificate Revocation List (CRL) and we should check with them.The Client, in this case ServiceNow. Will send a revocation request to the specified URL above. We will the get an OCSP response. An OCSP response is what an OCSP responder returns when it receives a request about the revocation status of a certificate. The request / response protocol is specified in RFC 2560. The responses themselves are signed by the responder and they can have an independent life; this means that a given OCSP response can be considered as a specialized CRL which talks about a single certificate.Please note In London, we introduced certificate revocation check , which changed the certification verification process from evaluating the first and second level certs in the cert chain to evaluate all certs in the cert chain. Because of this customers who are making API calls to utilizing the high security plugin are now at the risk of getting 403 errors as they may not have the full cert chain defined in their instance trust store. To disable these checks you can set the property com.glide.communications.httpclient.debug_verify_hostname to 'false' Certificate Chains All clients e.g. browsers and ServiceNow, will contain a certificate bundle. A CA bundle is a file that contains root and intermediate certificates. The end-entity certificate along with a CA bundle constitutes the certificate chain. This bundle does not change unless the Certificate Authorities change their certificates or they expire. If a customer Server we connect to has a Certificate chain signed by a common ruputable CA e.g. Entrust. We already have these in our CA bundle so we can verify the entire certificate chain. We MUST be able to verify the Certificate chain. You can use the first OpenSSL Command above to check what Certificates the chain contains. if Required you need to add them to the instance.