Hi Robert,
I've patched our ARGUS server with your rpm (listed below), updated all
systems to lcg-CA (or whatever) 1.88-1, and all is well.
Cheers,
Ste
On 2017-11-29 19:01, Robert Frank wrote:
> Hi all,
>
> I think I've tracked down the source of the problem.
>
> When bouncycastle verifies the certificate paths it compares the chain
> it gets from the server with the local installed certificates.
> If there's a difference in a CA certificate in the same position
> (which is the case for 2B as it has changed) it executes a code block
> that is never executed otherwise.
> Long story short, in the SL6 version it executes the following method
> at some point:
>
> private static boolean isDeltaCRL(X509CRL crl)
> {
> Set critical = crl.getCriticalExtensionOIDs();
> return
> critical.contains(RFC3280CertPathUtilities.DELTA_CRL_INDICATOR);
> }
>
> If there are no critical extensions in the crl, the functions returns
> null, causing a null pointer exception and the problems.
>
> They have fixed that in newer bouncycastle versions (eg CentOS 7):
>
> private static boolean isDeltaCRL(X509CRL crl)
> {
> Set critical = crl.getCriticalExtensionOIDs();
> if (critical == null)
> {
> return false;
> }
> return
> critical.contains(RFC3280CertPathUtilities.DELTA_CRL_INDICATOR);
> }
>
> I've built an SL6 bouncycastle rpm which uses the fixed implementation
> of that function:
>
> rpm:
> http://mirror.tier2.hep.manchester.ac.uk/Repositories/local/6/x86_64/bouncycastle-1.46-1.el6.1.noarch.rpm
> src:
> http://mirror.tier2.hep.manchester.ac.uk/Repositories/local/6/sources/bouncycastle-1.46-1.el6.1.src.rpm
> patch:
> http://mirror.tier2.hep.manchester.ac.uk/tier2/deltacrl.patch
>
> After installing the rpm, my problems with the java voms clients
> disappeared.
>
> More testing is needed though.
>
> An alternative fix could be for the CA to add some critical extensions
> to the CRLs :-).
>
> Cheers,
> Robert
>
>
> On 29/11/17 17:56, Simon Fayer wrote:
>> Hi Robert,
>>
>> Hmm, we replaced the CA cert in /etc/grid-security/certificates, but
>> didn't
>> restart the daemons: this appeared to fix the problems with the
>> voms-proxy-init client. Perhaps it's something in the returned proxy
>> chain
>> that crashes it rather than the SSL connection itself?
>>
>> (I just tested it now and voms.gridpp.ac.uk & voms02.gridpp.ac.uk were
>> broken again for me, despite using the sha1 CA for their SSL
>> connections
>> (my test client was EL6.9 with UI
>> /cvmfs/grid.cern.ch/umd-sl6ui-test/etc/profile.d/setup-ui-example.sh,
>> requesting a gridpp proxy ))
>>
>> Regards,
>> Simon
>>
>>
>> On Wed, Nov 29, 2017 at 05:33:48PM +0000, Robert Frank wrote:
>>> Hi Daniela,
>>>
>>> the daemons on voms03 return a sha256 signed CA cert in the chain:
>>>
>>> echo "" | openssl s_client -connect voms03.gridpp.ac.uk:15000
>>> -showcerts 2>/dev/null | sed -n '/^ 1 s:/,/^ 2
>>> s:/{/^-----BEGIN/,/^-----END/p}' | openssl x509 -noout -text | sed -n
>>> 's/^\s*Signature Algorithm:\s*//p'
>>> sha256WithRSAEncryption
>>> sha256WithRSAEncryption
>>>
>>> voms02 returns sha1 (and so does voms):
>>>
>>> echo "" | openssl s_client -connect voms02.gridpp.ac.uk:15000
>>> -showcerts 2>/dev/null | sed -n '/^ 1 s:/,/^ 2
>>> s:/{/^-----BEGIN/,/^-----END/p}' | openssl x509 -noout -text | sed -n
>>> 's/^\s*Signature Algorithm:\s*//p'
>>> sha1WithRSAEncryption
>>> sha1WithRSAEncryption
>>>
>>> I think it's actually good that one of the servers is using the new
>>> CA certificates. Users that use the java voms client (which seems to
>>> be the default nowadays) and already have the new CA certificate can
>>> still get proxies this way. We already had a ticket from a na62 user
>>> who couldn't get a proxy.
>>> Yes, most users will be seeing error messages, but the fall-back
>>> should pick one working server.
>>>
>>> Cheers,
>>> Robert
>>>
>>> On 29/11/17 16:51, Daniela Bauer wrote:
>>>> Are you sure any of the vomsserevrs still have the new cert on ?
>>>> voms03
>>>> certainly doesn't and I'm (almost) sure neither does the
>>>> Manchester one. I couldn't just put a GridPP Brexit on my
>>>> conscience.
>>>>
>>>> Regards,
>>>> Daniela
>>>>
>>>> On 29 November 2017 at 16:38, Jensen, Jens (STFC,RAL,SC) <
>>>> [log in to unmask]> wrote:
>>>>
>>>>> Just to follow up on this, I happened to be in a call with Mischa
>>>>> from
>>>>> NIKHEF earlier today and we took some time after the call to
>>>>> discuss
>>>>> this peculiar problem. Mischa says he can replicate the problem -
>>>>> although he is not a member of a GridPP-hosted VO, he can contact
>>>>> the
>>>>> VOMS server and trigger the error in the client.
>>>>>
>>>>> It seems to be due to an ancient BouncyCastle library (1.46) on
>>>>> SL6, as
>>>>> Steve also mentioned in the call this morning.
>>>>>
>>>>> Unfortunately Mischa says it's not possible to backport a working
>>>>> BC
>>>>> library because they make a lot of incompatible changes between
>>>>> releases.
>>>>>
>>>>> Curiously, I just set up an SL6 (6.9) box in the cloud and I cannot
>>>>> replicate the error. What am I missing? This is using Java 1.7.0
>>>>> and UMD3.
>>>>>
>>>>> [jj47@vm102 ~]$ rpm -qa|grep igtf
>>>>> ca_policy_igtf-iota-1.88-1.noarch
>>>>> ca_policy_igtf-slcs-1.88-1.noarch
>>>>> ca_policy_igtf-classic-1.88-1.noarch
>>>>> ca_policy_igtf-mics-1.88-1.noarch
>>>>> [jj47@vm102 ~]$ rpm -qa|grep bouncy
>>>>> bouncycastle-1.46-1.el6.noarch
>>>>> bouncycastle-mail-1.46-2.el6.noarch
>>>>> [jj47@vm102 ~]$ voms-proxy-destroy
>>>>> [jj47@vm102 ~]$ voms-proxy-init3 -voms gridpp -vomses
>>>>> /etc/vomses/gridpp-voms02.gridpp.ac.uk
>>>>> Enter GRID pass phrase for this identity:
>>>>> Contacting voms02.gridpp.ac.uk:15000
>>>>> [/C=UK/O=eScience/OU=Oxford/L=OeSC/CN=voms02.gridpp.ac.uk]
>>>>> "gridpp"...
>>>>> Remote VOMS server contacted succesfully.
>>>>>
>>>>>
>>>>> Created proxy in /tmp/x509up_u500.
>>>>>
>>>>> Your proxy is valid until Thu Nov 30 04:24:25 GMT 2017
>>>>> [jj47@vm102 ~]$ voms-proxy-destroy
>>>>> [jj47@vm102 ~]$ voms-proxy-init3 -voms gridpp -vomses
>>>>> /etc/vomses/gridpp-voms.gridpp.ac.uk
>>>>> Enter GRID pass phrase for this identity:
>>>>> Contacting voms.gridpp.ac.uk:15000
>>>>> [/C=UK/O=eScience/OU=Manchester/L=HEP/CN=voms.gridpp.ac.uk]
>>>>> "gridpp"...
>>>>> Remote VOMS server contacted succesfully.
>>>>>
>>>>>
>>>>> Created proxy in /tmp/x509up_u500.
>>>>>
>>>>> Your proxy is valid until Thu Nov 30 04:24:52 GMT 2017
>>>>> [jj47@vm102 ~]$ voms-proxy-destroy
>>>>> [jj47@vm102 ~]$ voms-proxy-init3 -voms gridpp -vomses
>>>>> /etc/vomses/gridpp-voms03.gridpp.ac.uk
>>>>> Enter GRID pass phrase for this identity:
>>>>> Contacting voms03.gridpp.ac.uk:15000
>>>>> [/C=UK/O=eScience/OU=Imperial/L=Physics/CN=voms03.gridpp.ac.uk]
>>>>> "gridpp"...
>>>>> Remote VOMS server contacted succesfully.
>>>>>
>>>>>
>>>>> Created proxy in /tmp/x509up_u500.
>>>>>
>>>>> Your proxy is valid until Thu Nov 30 04:29:27 GMT 2017
>>>>>
>>>>> [jj47@vm102 ~]$ voms-proxy-info -all
>>>>> subject : /C=UK/O=eScience/OU=CLRC/L=RAL/CN=jens sha2
>>>>> jensen/CN=198921768
>>>>> issuer : /C=UK/O=eScience/OU=CLRC/L=RAL/CN=jens sha2 jensen
>>>>> identity : /C=UK/O=eScience/OU=CLRC/L=RAL/CN=jens sha2 jensen
>>>>> type : RFC3820 compliant impersonation proxy
>>>>> strength : 1024
>>>>> path : /tmp/x509up_u500
>>>>> timeleft : 11:53:48
>>>>> key usage : Digital Signature, Key Encipherment, Data Encipherment
>>>>> === VO gridpp extension information ===
>>>>> VO : gridpp
>>>>> subject : /C=UK/O=eScience/OU=CLRC/L=RAL/CN=jens sha2 jensen
>>>>> issuer :
>>>>> /C=UK/O=eScience/OU=Imperial/L=Physics/CN=voms03.gridpp.ac.uk
>>>>> attribute : /gridpp/Role=NULL/Capability=NULL
>>>>> timeleft : 11:53:48
>>>>> uri : voms03.gridpp.ac.uk:15000
>>>>>
>>>>
>>>>
>>>>
|