The primary, publicly exposed Web Server for WebCenter is IIS. Thus IIS does the production SSL processing. IIS does not use OpenSSL. So, it is not susceptible to this specific bug. IIS serves web content unencrypted over HTTP on port 80 and encrypted over HTTPS on port 443 (using encryption is highly recommended). These are the only ports that should be accessible from "untrusted" locations (this might include sections of your corporate network).
As of WebCenter 12, the Tomcat distributed with WebCenter contains an embedded Apache Web Server which includes OpenSSL. This Tomcat is configured with SSL on port 8443 with a self-signed certificate for testing purposes only.
Every released version of WebCenter (12.0 to 12.1.2) is shipped with a version of the OpenSSL 1.0.0 branch, which is NOT susceptible to the bug.
Alpha/ Beta releases of WebCenter 14 contain a version of the OpenSSL 1.0.1 branch, which is susceptible to the bug. So, for these versions, port 8443 does expose the bug. For this reason this port needs to be protected against any access from untrusted locations.
If you have proper security policy in place, this should be the case already (only ports 80 and 443 should be exposed). If you consider all systems as untrusted, even the ones that sit on the same LAN (for e.g.: you rely on an external firewall), please use the Windows Firewall to prevent access to this port from any other system.
This situation is not considered as critical. It might however get incorrectly flagged as such in automated security scans. For this reason, we will look to address this by the WebCenter 14 release.
As of WebCenter 14 builds cd883 and r5, the Tomcat shipped with WebCenter makes use of TCNative 1.1.30 which is built using OpenSSL 1.0.1g. This version of OpenSSL fixes the Heartbleed bug. So, the problem will no longer exist in any part of WebCenter.