Hi Daniela,
Yes, David Groep also suggested this. While adding an extension to the
CRL is Mostly Harmless®, making it critical is not... it risks breaking
even more stuff. Before I do anything I'll have a quick look at
existing CRLs and see if any have critical extensions - I suspect there
are none.
If I have to pick one, looking through RFC 5280, section 5.2, suggests
the AKI (section 5.2.1) is least likely to harm anything if made critical.
Cheers
--jens
On 30/11/2017 10:38, Daniela Bauer wrote:
> Hi All,
>
> Can we please *not* go down the "every site must update their
> software" route ? This will take years to fix. (I'll take Steve 6.4 as
> a case in point....;-)
>
> @Jens - would you be able to generate a cert with the critical
> extension and we can try it out ?
> Everyone updates their CAs, so it there is anyway to fix it there,
> this is the way forward.
>
> Thanks,
> Daniela
>
>
> On 30 November 2017 at 10:28, Kashif Mohammad
> <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
>
>
> >>>>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
> <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
> <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
> <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
> <http://voms.gridpp.ac.uk> & voms02.gridpp.ac.uk
> <http://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-
> <http://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 <http://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 <http://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] <mailto:[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
> <http://gridpp-voms02.gridpp.ac.uk>
> >>>>>>>>>>> Enter GRID pass phrase for this identity:
> >>>>>>>>>>> Contacting voms02.gridpp.ac.uk:15000
> <http://voms02.gridpp.ac.uk:15000>
> >>>>>>>>>>>
> >>>>[/C=UK/O=eScience/OU=Oxford/L=OeSC/CN=voms02.gridpp.ac.uk
> <http://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
> <http://gridpp-voms.gridpp.ac.uk>
> >>>>>>>>>>> Enter GRID pass phrase for this identity:
> >>>>>>>>>>> Contacting voms.gridpp.ac.uk:15000
> <http://voms.gridpp.ac.uk:15000>
> >>>>>>>>>>>
> >>>>[/C=UK/O=eScience/OU=Manchester/L=HEP/CN=voms.gridpp.ac.uk
> <http://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
> <http://gridpp-voms03.gridpp.ac.uk>
> >>>>>>>>>>> Enter GRID pass phrase for this identity:
> >>>>>>>>>>> Contacting voms03.gridpp.ac.uk:15000
> <http://voms03.gridpp.ac.uk:15000>
> >>>>>>>>>>>
> >>>>[/C=UK/O=eScience/OU=Imperial/L=Physics/CN=voms03.gridpp.ac.uk
> <http://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
> <http://voms03.gridpp.ac.uk>
> >>>>>>>>>>> attribute : /gridpp/Role=NULL/Capability=NULL timeleft :
> >>>>>>>>>>> 11:53:48 uri : voms03.gridpp.ac.uk:15000
> <http://voms03.gridpp.ac.uk:15000>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
>
>
>
>
> --
> Sent from the pit of despair
>
> -----------------------------------------------------------
> [log in to unmask] <mailto:[log in to unmask]>
> HEP Group/Physics Dep
> Imperial College
> London, SW7 2BW
> Tel: +44-(0)20-75947810
> http://www.hep.ph.ic.ac.uk/~dbauer/
> <http://www.hep.ph.ic.ac.uk/%7Edbauer/>
|
