Let’s Encrypt certificates and Ariba
Let’s Encrypt, a non-profit certificate authority (CA), reported the issue of 200 million certificates by Feb this year. Till recently getting a standard CA-signed certificate for testing/dev purposes required just the same process as for production, meaning it took time and was costly. That is no longer the case because Let’s encrypt is giving away certificates for free and these can be obtained very quickly. Actually, many popular hosting providers already provide some automation for the certificate issue and renewal. The mechanics of LE are explained here https://letsencrypt.org/how-it-works/ in details.
The good news is that the LE Certificate Authority (CA) was recently added to the SAP Ariba trust store (Ariba Network, Ariba Cloud Integration Gateway, Apps). There’s a caveat, though, which is linked to SNI support.
Ariba requires that SAP ERP backends that connect to Ariba Cloud Integration Gateway enabled the Server Name Indication support (see Ariba Support Note #191073 & SAP Support Note #2970307: https://launchpad.support.sap.com/#/notes/2970307 ). That is because Ariba Cloud Integration Gateway presents SNI certificates, so a client that does not support SNI will fail with an SSL handshake exception:
I079489$ openssl s_client -connect testacig.ariba.com:443 -prexit CONNECTED(00000006) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1 verify return:1 depth=0 C = DE, ST = Baden-W\C3\BCrttemberg, L = Walldorf, O = SAP SE, CN = *.cf.eu10.hana.ondemand.com verify return:1 --- Certificate chain 0 s:/C=DE/ST=Baden-W\xC3\xBCrttemberg/L=Walldorf/O=SAP SE/CN=*.cf.eu10.hana.ondemand.com i:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1 1 s:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1 i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA --- Server certificate -----BEGIN CERTIFICATE-----
Ariba Cloud Integration Gateway also respects the SNI certificates presented by the HTTPs endpoints defined for the back-ends. Similarly, Ariba Sourcing or Ariba Procurement will also let you define an outbound integration endpoint pointing to an HTTPs address that uses an SNI certificate. Sadly, this is not the case for Ariba Network, were SNI is not supported. What does this mean? Well, before SNI became supported each physical IP could only serve one virtual host protected by an SSL certificate. With SNI the certificate is chosen based on the hostname provided by the client (in the ClientHello message). Because Ariba Network does not support this, if you define a backend connection in Ariba Network admin, you need to ensure that hostname maps to an IP that server a a non-SNI certificate for that hostname. Use the following link to check what kind of certs SNI/non-SNI your site serves: https://www.ssllabs.com/ssltest/analyze.html?d=your.domain.name.com (change the url param naturally)
Aside: you might be wondering why Ariba Network does not support SNI if Java natively supports it since v1.7. I suspect that this is not disabled intentionally and will be fixed at some point.
In a nutshell, because of various technology stacks behind Ariba products, you will be able to use SNI certificates and a shared IP server for an external end-point configured for anything but Ariba Network, for the later you still need a non-SNI certificate and hence a dedicated IP.
Thanks Radek for sharing. I did not know about it 🙂 Very useful.