Fixing BEA-090504 Certificate Chain warnings after enabling Weblogic Administration port

02 Dec

After we enabled SSL on all our Weblogic machines in our environment (multiple hosts) we enabled the Administration port for our domain:

The domain-wide administration port enables you to start a WebLogic Server instance in STANDBY state. It also allows you to separate administration traffic from application traffic in your domain. Because all servers in the domain must enable or disable the administration port at once, you configure the default administration port settings at the domain level. If you enable the administration port:
The administration port accepts only connections that specify administrator credentials. Connections that specify administrator credentials can use only the administration port. Because the administration port uses SSL, enabling the administration port requires that SSL must be configured for all servers in the domain. (source: Weblogic console)

Everything started up fine, however in the weblogic logfiles of every managed server we did see the following message:

<Warning> <Server> <server2> <rbx_dev_wls_01> <[STANDBY] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1322835992044> <BEA-090504> <Certificate chain received from server1.rubix.local - failed hostname verification check. Certificate contained server1 but check expected server1.rubix.local>

<Notice> <WebLogicServer> <server2> <rbx_dev_wls_01> <main> <<WLS Kernel>> <> <> <1322835992137> <BEA-000365> <Server state changed to RUNNING>

<Notice> <WebLogicServer> <server2> <rbx_dev_wls_01> <main> <<WLS Kernel>> <> <> <1322835992153> <BEA-000360> <Server started in RUNNING mode>

<Warning> <Log Management> <server2> <rbx_dev_wls_01> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1322835996646> <BEA-170011> <The LogBroadcaster on this server failed to broadcast log messages to the admin server. The Admin server may not be running. Message broadcasts to the admin server will be disabled.>

<Warning> <Server> <server2> <rbx_dev_wls_01> <[STANDBY] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1322835992044> <BEA-090504> <Certificate chain received from server1.rubix.local - failed hostname verification check. Certificate contained server1 but check expected server1.rubix.local>

The CN value of all our SSL certificates are based upon the basis hostname of the server. In this case the admin runs on server1 and the managed server on server2. The Managed Server performs a SSL hostname verification and this fails due to the fact that server1 is trying to communicate with server2 over channel server1.rubix.local but server receives the identity based upon CN=server1.

We needed to override Weblogic to use the server1 communication channel instead of the server1.rubix.local channel which it default is trying to use. This could be easily fixed by going to the Weblogic console and check each Managed Server and Admin server for it’s Listen Address.

I’ve seen more problems with Weblogic environments (also on Windows) where the Listen Address is not configured. For me reason enough to use a best-practice to always configure the Listen Address with a fixed value.


Posted by on 02-12-2011 in Weblogic


Tags: ,

3 responses to “Fixing BEA-090504 Certificate Chain warnings after enabling Weblogic Administration port

  1. Ani

    07-09-2012 at 16:32

    Hi Jan, While this is a year & a half late and you might anyway be aware of this but here’s something from the Oracle docs on this topic:

    “If you do not explicitly specify a hostname with the -cn option, CertGen uses the JDK InetAddress.getHostname() method to get the hostname that it puts in the Subject common name. The getHostName() method works differently on different platforms. It returns a fully qualified domain name (FQDN) on some platforms (for example, Solaris) and a short host name on other platforms (for example, Windows NT). On Solaris, the result of InetAddress.getHostname() depends on how the hosts entry is configured in the /etc/nsswitch.conf file.

    If WebLogic Server is acting as a client (and by default host name verification is enabled), you need to ensure that the host name specified in the URL matches the Subject common name in the server certificate. Otherwise, connections will fail because the host names do not match.”

    So that probably explains why the server certificate was generated with CN=server1 and not CN=server1.rubix.local.

    But there is one thing that is confusing me here: Why does it say server1.local.rubix at one place and server1.rubix.local at another?

    Regards, Ani.

  2. jvzoggel

    18-09-2012 at 07:07

    Hi Ani, interesting regarding the JDK InetAddress.getHostname() method. Thanks !! About your remark mentioning the different FQDN that indeed was a typo. Most of my loggings are from client projects, so usually I replace their ciient specific naming conventions. I’ve quickly fixed it in the blog above. Kind regards Jan

  3. dheeraj

    23-02-2014 at 12:54

    Thanks Jan for this problem description and solution.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: