I've also updated bouncycastle on our ARGUS server with Robert's patched
RPM and everything seems to be working both on the server itself and on
our CREAM CE and DPM SE.
Cheers,
John
On 01/12/2017 09:45, sjones wrote:
> 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
>>>>>>
>>>>>
>>>>>
>>>>>
|