Thursday, July 30, 2015

Using Subject Alternative Names in certificates

if your site can be served via more than 1 hostname, you might have to set a "Subject Alternative Name" (SAN) with a comma separated list of all your valid hostnames.

The MAD thing is that is you use a SAN, your MAIN Common Name (certificate SUbject) will be ignored. So in your SAN list you should specify also the hostname that used to go in the Main subject.

Unless you do that, you will get a "Server's certificate does not match URL" in Chrome, or a "Mismatched Address" in IE. IE really stinks because its error message gives absolutely no extra info, while Chrome gives some extra context information. Shame on Microsoft.

Chrome full message says "This server could not prove that it is bla.acme.net; its security certificate is from pippo.acme.net . This may be caused by a misconfiguration or an attacker intercepting your connection"

The RFC which could bring some order in this chaos is here https://tools.ietf.org/html/rfc6125 and search for subjectAlternativeName .



Thursday, July 2, 2015

Unresolved Webapp Library references

Unresolved Webapp Library references See http://docs.oracle.com/cd/E13222_01/wls/docs92/programming/libraries.html

If your webapp requires a specific version of a library, you can use the container-descriptor/prefer-application-packages/package-name clause in the weblogic.xml of your webapp. But then you should also refer to the library specific version with another clause:

   <library-ref>
      <library-name>jax-rs</library-name>
        <specification-version>2.0</specification-version>
        <exact-match>false</exact-match>
    </library-ref>


This is only a library-ref, so the library must be made available in the config.xml:

  <library>
    <name>jax-rs#2.0@2.5.1</name>
    <target>icr_v00_25000_localhost</target>
    <module-type>war</module-type>
    <source-path>/path/to/yourlibrary.war</source-path>
    <security-dd-model>DDOnly</security-dd-model>
    <staging-mode>nostage</staging-mode>
    <plan-staging-mode xsi:nil="true"></plan-staging-mode>
    <cache-in-app-directory>false</cache-in-app-directory>
  </library>




otherwise you will get the dreaded "Unresolved Webapp Library references for ...."

On the whole I find these classloader and version issues an extremely uninteresting topic...

BEA-141196 The managed server could not update the configuration files during the registration with the deployment service



<Jul 2, 2015 10:31:52 AM CEST> <Error> <Management> <BEA-141196> <The managed server could not update the configuration files during the registration with the deployment service. The update failed due to an exception:
weblogic.management.DeploymentException: Exception occured while copying files
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.doUpdate(DataUpdate.java:307)
        at weblogic.deploy.internal.targetserver.datamanagement.ConfigDataUpdate.doUpdate(ConfigDataUpdate.java:102)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.update(DataUpdate.java:72)
        at weblogic.deploy.internal.targetserver.datamanagement.Data.commitDataUpdate(Data.java:118)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.updateFiles(RuntimeAccessDeploymentReceiverService.java:880)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.handleRegistrationResponse(RuntimeAccessDeploymentReceiverService.java:728)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.registerHandler(RuntimeAccessDeploymentReceiverService.java:699)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.start(RuntimeAccessDeploymentReceiverService.java:169)
        at weblogic.t3.srvr.ServerServicesManager.startService(ServerServicesManager.java:462)
        at weblogic.t3.srvr.ServerServicesManager.startInStandbyState(ServerServicesManager.java:167)
        at weblogic.t3.srvr.T3Srvr.initializeStandby(T3Srvr.java:881)
        at weblogic.t3.srvr.T3Srvr.startup(T3Srvr.java:568)
        at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:469)
        at weblogic.Server.main(Server.java:71)
Caused By: java.io.FileNotFoundException: /acme/appsrv/domains/pippodomain/config/pref/preferences.xml (Permission denied)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:145)
        at weblogic.utils.FileUtils.writeToFile(FileUtils.java:115)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.copy(DataUpdate.java:265)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.copyOrExtractTo(DataUpdate.java:202)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.updateLocalData(DataUpdate.java:168)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.doUpdate(DataUpdate.java:299)
        at weblogic.deploy.internal.targetserver.datamanagement.ConfigDataUpdate.doUpdate(ConfigDataUpdate.java:102)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.update(DataUpdate.java:72)
        at weblogic.deploy.internal.targetserver.datamanagement.Data.commitDataUpdate(Data.java:118)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.updateFiles(RuntimeAccessDeploymentReceiverService.java:880)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.handleRegistrationResponse(RuntimeAccessDeploymentReceiverService.java:728)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.registerHandler(RuntimeAccessDeploymentReceiverService.java:699)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.start(RuntimeAccessDeploymentReceiverService.java:169)
        at weblogic.t3.srvr.ServerServicesManager.startService(ServerServicesManager.java:462)
        at weblogic.t3.srvr.ServerServicesManager.startInStandbyState(ServerServicesManager.java:167)
        at weblogic.t3.srvr.T3Srvr.initializeStandby(T3Srvr.java:881)
        at weblogic.t3.srvr.T3Srvr.startup(T3Srvr.java:568)
        at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:469)
        at weblogic.Server.main(Server.java:71)




If you look in Oracle Support, you get a Document "Error Starting WebLogic Server: BEA-141196: The managed server could not update the configuration files during the registration with the deployment service (Doc ID 1461960.1)" advising to change the rights of those files/folders to be updated.

In our case the reality was MUCH more diabolical: the managed server was contacting the ADMIN of ANOTHER DOMAIN which was mistakenly configured to run on the same box with the same admin port.... so the WRONG admin was updating the configuration of the Managed Server, even if it was belonging to a different domain.

So the solution is just to make sure that each domain runs with unique ports. It's a bit crazy that the Managed Server was accepting communication with a different domain...