>>>>I've patched the GridPP VOMS admin server (unfortunately, they don't
>>>>depend on the bouncycastle rpm, they ship it themselves as part of the
>>>>voms-admin-server rpm, I just hope they haven't modified it). Now
>>>>everyone should be able to access the web page regardless of which CA
>>>>version is installed on the server or in the browser.
>>>>I've also updated the trust anchors to 1.88.
>>>>
>>>>Kashif, Pete: Can you leave the trust anchor version at 1.87 on voms02 for
>>>>now, so we still have a server with the old version that clients can use
>>>>which haven't updated their CAs yet ?
I haven't updated trust anchor to 1.88 on voms server yet. I will leave it to 1.87 for time being.
Kashif
>>>>Cheers,
>>>>Robert
>>>>
>>>>On 30/11/17 08:20, Robert Frank wrote:
>>>>> Hi Steve,
>>>>>
>>>>> it needs to be installed on all SL6 machines that run any Java program
>>>>(client or server) that requires any type of certificate validation. That's any
>>>>Java client in general as they should be validating the server certificate and
>>>>any Java server the requires client certificate authentication (which in our
>>>>case covers pretty much everything).
>>>>> So far, I've only tested it with the java voms client, I don't know yet if it
>>>>will work with Argus or CREAM, or if there are other issues.
>>>>>
>>>>> Cheers,
>>>>> Robert
>>>>>
>>>>> On 29/11/17 20:09, sjones wrote:
>>>>>> Robert,
>>>>>>
>>>>>> does the patched copy of BouncyCastle need to be installed on ARGUS
>>>>server, or client (e.g. CEs. SEs) or all the above?
>>>>>>
>>>>>> 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/source
>>>>>>> s/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.s
>>>>>>>> h,
>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
|