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
>>>>
>>>
>>>
>>>
|