The customer reported:

A security audit showed several open ports with SSL servers running. This is
OK but some of them allowed connections from clients with weak ciphers (like
DES). First we identified the component and found cacao, the Common Agent
Container. It is installed during JumpStart and later updated by SunCluster.

I found with
        cacaoadm list-modules
that several Sun Cluster components are registered in this thing. So it is
unlikely, that we can disable it. First question: is this right? Do we have
to live with the service
        svc:/application/management/common-agent-container-1:default
which results in the process
        root 3550 0.1 0.8209792131488 ? S 15:13:53 0:29 /usr/jdk/jdk1.5.0_15/bin/java -Xms4M -Xmx128M -Dcom.sun.management.jmxremote -Dfile.encoding=utf-8 -classpath /usr/share/lib/jdmk/jdmkrt.jar:/usr/share/lib/jdmk/jmxremote_optional.jar:/usr/lib/cacao/lib/cacao_cacao.jar -Djavax.management.builder.initial=com.sun.jdmk.JdmkMBeanServerBuilder -Dcacao.print.status=true -Dcacao.config.dir=/etc/cacao/instances/default -Dcom.sun.cacao.ssl.keystore.password.file=/etc/cacao/instances/default/security/password -Dcacao.monitoring.mode=smf com.sun.cacao.container.impl.ContainerPrivate

When we can disable it, we would obviously prefer this. How does this work?
A developer told me, he disabled it with
        svcadm disable svc:/application/management/common-agent-container-1:default
but after a reboot it was running again.

The next best solution (I think the one we have to go for) is to disable the
weak ciphers inside cacao. Unfortunately, I did not find anything in the
configuration files like
        /etc/cacao/instances/default/private/cacao.properties
I had a short look at the source code
        https://common-agent-container.dev.java.net/source/browse/common-agent-container/trunk/src
but without a working search function it was simply too much to click through.

To check, that weak ciphers are used I did
        cacaoadm get-param commandstream-adaptor-port
to get the open port, which can also be seen with pfiles in the above mentioned
process.
Then I connected to this port with
        /usr/sfw/bin/openssl s_client -connect localhost:11163 -cipher LOW
and was connected with the cipher EDH-RSA-DES-CBC-SHA. This means in
essence DES, which uses 56 bits, which is very weak.

Second question: What do I have to configure, to get an error in this case?
I still want to be able to connect with things like "-cipher AES" but DES (and
everything with too few key bits) should be disabled.

I played around with
/usr/jdk/instances/jdk1.5.0/jre/lib/security/sunpkcs11-solaris.cfg
where some disabled algorithms for Java are listed and added all constants
with RC4 in them from /usr/include/security/pkcs11t.h

  CKM_RC4
  CKM_RC4_KEY_GEN
  CKM_PBE_SHA1_RC4_128
  CKM_PBE_SHA1_RC4_40

I took RC4 simply because fewer CKM_ constants existed with RC4 than with DES.
On the other hand this configuration file is for all Java processes and I did
not intend to disturb any other processes. I simply hoped, nobody would use
RC4 anyway.

Then I restarted cacao with
        svcadm restart svc:/application/management/common-agent-container-1:default
but could still connect with
        /usr/sfw/bin/openssl s_client -connect localhost:11163 -cipher RC4
I got the cipher RC4-SHA.

This means, it was definitely the wrong configuration file. Where can I
configure this?

------

After some investigation, we came down to this not being such a problem, as they only got a weak cypher if they requested it - the system negotiated the strongest cipher available to both client and server. And this still didn't allow breaking of authorisation, it just covered how the communication was encrypted. The customer also misread what they were getting as DES, when it was actually 3DES, which they're satisfied with.

But it still leaves open the question about how they can configure all the providers across the system to effectively ban the use of weak ciphers if they want to? This RFE is to request that functionality.
We addressed the request in the fix of CR 6916074 with a more general solution.