[Xymon] sslcert question

Thu Apr 14 06:12:27 CEST 2011

lol. I tried this on an older box running apache 2.0 - same thing.  I'll
dig further. 

>>> On 4/14/2011 at 9:30 AM, in message
<8D17C43B4F1AC3498DE039AEA9381290732C59019E at VA3DIAXVS051.RED001.local>,
Tim
McCloskey <tm at freedom.com> wrote:
> Nope, I'm not using that sslcert feature --- so maybe I should stay
quiet on 
> this one :) 
> ________________________________________
> From: Phil Crooker [Phil.Crooker at orix.com.au] 
> Sent: Wednesday, April 13, 2011 4:53 PM
> To: Tim McCloskey
> Cc: xymon at xymon.com 
> Subject: RE: [Xymon] sslcert question
> 
> I think xymonnet does the checking directly. Henrik does have a
> "contest" program in the xymonnet src directory, I assume for
> troubleshooting, but it doesn't return the ssl stuff, just the
returned
> header.
> 
> The other system is RHEL 4.6 which is running the websphere - I ran
the
> openssl and got 45 ciphers, so what xymonnet returns is correct for
what
> is configured in IHS. IBM don't use mod_ssl, they wrote their own
thing.
> In the IHS config, you can specify which ciphers to use, similar to
the
> CipherSuite statement in apache.
> 
> Do you use this sslcert feature, are you having this problem?
> 
> 
>>>> On 4/14/2011 at 1:25 AM, in message
>
<8D17C43B4F1AC3498DE039AEA9381290732C59018D at VA3DIAXVS051.RED001.local>,
> Tim
> McCloskey <tm at freedom.com> wrote:
>> Could this be a component in xymon may be checking with openssl
(not
> via wget
>> https://)?  If openssl on the IBM box is compiled with those
ciphers
> disabled
>> that might explain it.  What do you get with openssl cipher -v on
the
> IBM
>> variant?
>>
>> ________________________________________
>> From: Phil Crooker [Phil.Crooker at orix.com.au] 
>> Sent: Wednesday, April 13, 2011 12:04 AM
>> To: Tim McCloskey
>> Cc: xymon at xymon.com 
>> Subject: RE: [Xymon] sslcert question
>>
>> Hi TIm,
>>
>> Same thing with your config. I tried a few settings and it always
>> displays the same complete list. It kinda looks like apache is just
>> returning all the cipher suites on the system - similar output to
>> "openssl cipher -v", rather than the configured/available ones.
>>
>> Odd.
>>
>> cheers, Phil
>>
>>
>>
>>>>> On 4/13/2011 at 3:25 PM, in message
>>
>
<8D17C43B4F1AC3498DE039AEA9381290732C59018B at VA3DIAXVS051.RED001.local>,
>> Tim
>> McCloskey <tm at freedom.com> wrote:
>>> Phil,
>>>
>>> That looks like an apache/openssl config concern.  What happens
> when
>> you
>>> force a more generic SSLCipherSuite?
>>>
>>> SSLCipherSuite HIGH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL
>>>
>>> Tim
>>>
>>>
>>> ________________________________________
>>> From: xymon-bounces at xymon.com [xymon-bounces at xymon.com] On Behalf
> Of
>> Phil
>>> Crooker [Phil.Crooker at orix.com.au] 
>>> Sent: Tuesday, April 12, 2011 10:36 PM
>>> To: xymon at xymon.com 
>>> Subject: [Xymon] sslcert question
>>>
>>> Hi all,
>>>
>>> I've been playing with the ssl networking tests and have an issue
>> with
>>> a host. I've setup SSL3/TLS1 on this particular server and
>> explicitly
>>> specified 256 and 168 bit ciphers.  On the sslcert page for that
> host
>> it
>>> lists the following ciphers even though anything less than 168
bits
>> is
>>> disabled. I confirmed separately using a browser that you can't
>> connect
>>> with the smaller cipher sizes and can with larger ones. We have
>> another
>>> site using IBM's version of apache (IHS) which does appear with
the
>>> correct available ciphers in the sslcert page. Any idea why are
the
>>> smaller ciphers showing as being enabled?
>>>
>>> This is SuSE Linux with: Apache/2.2.10 (Linux/SUSE) mod_ssl/2.2.10
>>> OpenSSL/0.9.8h
>>>
>>> apache config bits:
>>>
>>>         SSLCipherSuite
>>>
>>
>
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLI
>>>
>>
>
A256-SHA:CAMELLIA256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-M
>> D
>>> 5
>>>         SSLProtocol -all +SSLv3 +TLSv1
>>>
>>>
>>> thanks, Phil
>>> --------------------------------------------
>>>
>>>
>>> SSL certificate for https://gwweb.orix.com.au/gw/webacc expires in
>> 275
>>> days
>>>
>>>
>>> Server certificate:
>>>         subject:/C=AU/postalCode=2113/ST=NSW/L=Macquarie
>>> Park/streetAddress=1 Eden Park Drive/2.5.4.18=Locked Bag 2068,
> North
>>> Ryde, NSW 1670/O=ORIX Australia Corporation Limited/OU=Comodo
>> PremiumSSL
>>> Wildcard/CN=*.orix.com.au
>>>         start date: 2009-01-12 00:00:00 GMT
>>>         expire date:2012-01-12 23:59:59 GMT
>>>
>>> Available ciphers:
>>> Cipher 0: DHE-RSA-AES256-SHA (256 bits)
>>> Cipher 1: DHE-DSS-AES256-SHA (256 bits)
>>> Cipher 2: AES256-SHA (256 bits)
>>> Cipher 3: DHE-RSA-CAMELLIA256-SHA (256 bits)
>>> Cipher 4: DHE-DSS-CAMELLIA256-SHA (256 bits)
>>> Cipher 5: CAMELLIA256-SHA (256 bits)
>>> Cipher 6: EDH-RSA-DES-CBC3-SHA (168 bits)
>>> Cipher 7: EDH-DSS-DES-CBC3-SHA (168 bits)
>>> Cipher 8: DES-CBC3-SHA (168 bits)
>>> Cipher 9: DES-CBC3-MD5 (168 bits)
>>> Cipher 10: DHE-RSA-AES128-SHA (128 bits)
>>> Cipher 11: DHE-DSS-AES128-SHA (128 bits)
>>> Cipher 12: AES128-SHA (128 bits)
>>> Cipher 13: DHE-RSA-CAMELLIA128-SHA (128 bits)
>>> Cipher 14: DHE-DSS-CAMELLIA128-SHA (128 bits)
>>> Cipher 15: CAMELLIA128-SHA (128 bits)
>>> Cipher 16: RC2-CBC-MD5 (128 bits)
>>> Cipher 17: RC4-SHA (128 bits)
>>> Cipher 18: RC4-MD5 (128 bits)
>>> Cipher 19: RC4-MD5 (128 bits)
>>> Cipher 20: EDH-RSA-DES-CBC-SHA (56 bits)
>>> Cipher 21: EDH-DSS-DES-CBC-SHA (56 bits)
>>> Cipher 22: DES-CBC-SHA (56 bits)
>>> Cipher 23: DES-CBC-MD5 (56 bits)
>>> Cipher 24: EXP-EDH-RSA-DES-CBC-SHA (40 bits)
>>> Cipher 25: EXP-EDH-DSS-DES-CBC-SHA (40 bits)
>>> Cipher 26: EXP-DES-CBC-SHA (40 bits)
>>> Cipher 27: EXP-RC2-CBC-MD5 (40 bits)
>>> Cipher 28: EXP-RC2-CBC-MD5 (40 bits)
>>> Cipher 29: EXP-RC4-MD5 (40 bits)
>>> Cipher 30: EXP-RC4-MD5 (40 bits)
>>>
>>>
>>> _______________________________________________
>>> Xymon mailing list
>>> Xymon at xymon.com 
>>> http://lists.xymon.com/mailman/listinfo/xymon 
>> --
>>
>> This message from ORIX Australia might contain confidential and/or
>> privileged information. If you are not the intended recipient, any
> use,
>> disclosure or copying of this message (or of any attachments to it)
> is
>> not authorised.
>>
>> If you have received this message in error, please notify the
sender
>> immediately and delete the message and any attachments from your
>> system. Please inform the sender if you do not wish to receive
> future
>> communications by email.
>>
>> ORIX handles personal information according to a Privacy Policy
that
> is
>> consistent with the National Privacy Principles. Please let us know
> if
>> you would like a copy. It is also available at
http://www.orix.com.au 
> .