The shift to cloud computing offers a huge number of benefits, but also does introduce some potential risks; the most obvious of these is the need to enable integrations – and by implication, the need to transmit sensitive data – across public networks. Fortunately, we already have a pretty good set of standards and techniques for doing this, with the HTTPS (Secure HTTP) protocol taking care of the grunt-work of encryption and server authentication at the transport layer. The purpose of this article is to explore the usage of HTTPS across the various services that comprise the Oracle Public Cloud.
A brief re-introduction to HTTPS
There is nothing new or particularly special about the HTTPS protocol. As with most secure protocols, it’s really just the combination of a few building blocks: HTTP as the application-level protocol for hypertext transfer, Transport Layer Security (TLS) as the underlying transport-level security mechanism and a healthy dose of public key cryptography to enable server authentication and key exchange. Here’s a really good primer, in case you want to learn more.
TLS authentication can be either one-way (where only the server presents a certificate) or two-way (where the client also has a certificate to prove its identity). For the purposes of this discussion, though, we will stick to one-way TLS, since that’s what it used in the vast majority of OPC use cases.
There are two major use cases that are important here, each involving a different type of HTTPS client. If the use case is a direct front-end (UI) interaction with an OPC service, then the client is a web browser. In the case of a back-end (server-to-server) call, it’s another service (whether on-premise or in the cloud) acting as an HTTP client in the context of a service invocation.
During the TLS handshake, the server sends a certificate to the client, containing some attributes to identify itself as well as a public key. The intention here is that the client should inspect the certificate in order to verify the server’s identity, but the whole process only works if the client knows that it can trust the certificate in the first place. This is why a certificate will always be accompanied by a digital signature that asserts its validity. The client makes a decision as to whether it trusts the certificate based on whether it trusts the entity that signed the certificate (and hence vouched for the server’s identity). Each client starts out by trusting a number of root CA certificates and any other certificate signed directly or indirectly by one of these trusted CA certificates will be itself be trusted. All of the well-known CA’s are included in this pre-configured trusted list, meaning you can easily and quickly purchase a certificate from one of them and know that you won’t have any “trust issues” in the future.
The other option is to roll your own; to use commonly-available utilities such as OpenSSL to generate self-signed certificates. In this case, there is no mutually-trusted 3rd party between client and server, hence you’ll need to take steps to configure each client to explicitly trust the certificate chain that the server presents. I say “chain” because the typical way to do this is to generate a single self-signed root certificate and then use that certificate to sign all of your server certificates. That ends up being a far more effective way to manage the explicit configuration of trust, since you don’t need to import each individual server certificate into your client’s trust store. Even with this latter approach, trying to manage explicit trust of self-signed certificates is a nightmare that does not work at all well when the clients are web browsers. For securing point-to-point HTTP communication between two services, though, it becomes more feasible (and in some ways more cost effective) to use self-signed certificates and explicitly-configured trust.
So what about Oracle Public Cloud?
Oracle’s Public Cloud offering is, of course, vast and comprises a plethora of useful services, divided into a number of different major categories (SaaS, PaaS and IaaS). Since the main focus of this article is to explore the intricacies of HTTPS in Oracle Public Cloud – and specifically how a client (be it browser or service consumer) can establish a secure connection to an OPC end-point, it follows that we need to understand which of the above certificate models are used.
There are two broad categories here:
SaaS and Non-Compute based PaaS
All of Oracle’s Software as a Service (SaaS) offerings, including Sales Cloud, HCM Cloud, Marketing Cloud, ERP Cloud and many others, fall into this first category. Also in this category are those Platform as a Service (PaaS) that are non-compute based, including things like Integration Cloud Service, SOA Cloud Service, Mobile Cloud Service and Document Cloud Service.
Services in this category are configured to use a certificate signed by a trusted 3rd-party CA (VeriSign). Looking at a specific example of an ICS tenant URL and following the certificate chain, we see that it looks as follows:
Connected to peer host integrationtrial7892-caoracletrial93012.integration.us2.oraclecloud.com Retrived 3 certificates Certificate 1 Issued to: CN=*.integration.us2.oraclecloud.com, O=Oracle Corporation, L=Redwood Shores, ST=California, C=US Issued by: CN=Symantec Class 3 Secure Server CA - G4, OU=Symantec Trust Network, O=Symantec Corporation, C=US Certificate 2 Issued to: CN=Symantec Class 3 Secure Server CA - G4, OU=Symantec Trust Network, O=Symantec Corporation, C=US Issued by: CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Certificate 3 Issued to: CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issued by: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
The implication is that virtually any HTTPS client attempting to connect to an end-point presented by a service within this category will be able to do so without requiring any additional configuration. Trust is pre-configured since the VeriSign CA certificate above is included in most client trust stores by default.
IaaS and Compute based PaaS
This category includes all of the Infrastructure as a Service (IaaS) offerings within the Oracle Compute Cloud, as well as those PaaS services – such as Java Cloud Service and Database Cloud Service – that expose and provide access to the underlying Oracle Compute virtual machines.
Instances of these service offerings will not be provisioned along with automatically-trusted certificates, mainly due to the “bring your own host name” policy that applies to such instances. When an instance of, say, JCS is provisioned, the customer is provided with a public IP address and would then need to assign a host name (within their own domain) to that public IP. Since the certificate used by whatever web tier is deployed to that instance is always tied to the host name, it follows that the customer must obtain and install their own certificate as well. Again here, there are three options:
Purchase a certificate from a 3rd-party certificate authority. This is the simplest and most recommended option (although obviously not the cheapest) since the certificate obtained in this way would be automatically trusted by clients. There will most likely be no need for any further configuration in order to enable a trusted HTTPS connection to the service from either web browser or REST clients.
Use your own self-signed certificate authority. This option saves on the cost of purchasing a certificate, but does result in the need for explicitly configuring trust on each client. In this case, your organisation essentially becomes its own CA. Clients will need to be configured to trust the self-signed root certificate (this is done by importing that certificate into each browser and HTTP Client trust store), but since all server certificates are chained back to this one self-signed certificate, there is no further configuration required on a per server basis.
Generate a self-signed certificate per server. This option requires explicit trust configuration of every client for every server. It is perhaps only suited for development environments due to the complexity involved.
We’ve spoken a lot about needing to explicitly configure certificate trust when self-signed certificates are used. At a high-level, this process will involve the following steps:
1 – EITHER generate a self-signed server certificate, OR generate a key-pair and a certificate request, which your CA will use to issue a server certificate
2 – install the certificate and configure the server to use that certificate for HTTPS
3 – obtain the root CA certificate and import this into the client’s trust store
In a forthcoming post, I will share more explicit details regarding the configuration of some popular OPC service combinations to enable trust where it is not pre-configured.
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission