Many servers including those Servers which are hosted by Content Distribution Systems such as CloudFront are being co-hosted alongwith many other servers on a single IPv4 address. These servers are only accessible when Clients include TLS extension server_name_indication (SNI) from rfc6066 into their ClientHello handshake messages. Sending TLS extensions is unfortunately not backwards compatible with a small, but non-marginal set of old Servers, therefore TLS extensions are not sent by default. Sending of TLS extension for SAP Netweaver 741+ Kernels can be enabled through profile parameter icm/HTTPS/client_sni_enabled starting with Kernel Patch Document 2124480. And sending of TLS extension SNI as the client can alternatively be enabled in 722 Kernel patch no 223 and higher through profile parameter ssl/client_sni_enabled. View SAP Document 2384290 for more info.
The Microsoft SChannel in Windows 2008R2 and Windows 2012R2 incorrectly chokes and abort the TLS handshake when a client offers TLSv1.2 in an extensionless ClientHello handshake message with ClientHello.client_version = TLSv1.2 and the certificate of the server is signed with sha256WithRsaEncryption. Using CommonCryptoLib 8.4.48+ and enable PFS cipher suites (ssl/client_ciphersuites=150:PFS:HIGH) are the most recommended methods to overcome this Microsoft SChannel shortcoming. Another less recommended method is to limit the protocol version to TLSv1.1 on the Microsoft server side (this server-side limit was the default in original Windows 2008R2) or also to limit the protocol version to TLSv1.1 on the SAP client side (ssl/client_ciphersuites=400:HIGH).
The Microsoft Windows 2012 ADFS chokes and aborts on TLS handshakes from those TLS client which do not include TLS extension server_name_indication as it fails to define a suitable default server certificate. Therefore the possible methods to overcome this problem of Windows 2012 is to manually add the the missing mapping of a default server certificate on the Microsoft Server, or enabling sending of TLS extension SNI in SAP Netweaver 742+ clients as described in SAP Document 2124480, or in Netweaver 722+ clients as described in SAP Document 2384290, or also by manually fixing the missing backwards compatibility in Windows 2012R2.
Protocol option "BC" (Backwards Compatibility) is needed for interoperability via JavaSE 6 (still used in Android 4.4 and several other J2EE servers), Microsoft Internet Explorer (MSIE) Version 6 on Windows XP and Windows 2003, Firefox up to Version 3.0 etc, mostly older, browsers and SSL clients.
Background: Windows XP and 2003 was delivered with MSIE Version 6, and SSLv2 is activated and by default the TLSv1.0 is deactivated. Now when we upgrade MSIE to Version 7 or 8, the SSLv2is gets deactivated and TLSv1.0 is activated. However this MSIE upgrade does not change any the basic attributes of the SChannel component of the underlying Windows version.
The attributes which can be used by Microsoft Internet Explorer for SSL or TLS are determined by the capabilities and attributes of the underlying operating system version, especially the security provider SChannel and the Microsoft CryptoAPI despite the browser version user have installed.
Some of these attributes are available on older versions of Microsoft Windows only after installing Microsoft HotFix manually.
Microsoft SChannel support for AES cipher suites:
| XP 32-bit: | --- |
| 2003, XP 64-bit: | www.support.microsoft.com/kb/948963 |
Microsoft CryptoAPI Support for SHA256-based digital signatures, includes
XP 32+64, 2003 :- www.support.microsoft.com/kb/968730
Microsoft SChannel recommends using AES-based cipher suite (rfc3268) of SAPCRYTPOLIB pl28+ only in combination with protocol version TLSv1.0 and higher since Windows Vista (plus Windows 2003 after installing Microsoft Hotfix 948963 manually.
Google Chrome, Firefox 3+, and OpenSSL 0.9.8+ all support AES-based suites both on Windows XP and in combination with SSLv3.