The new GeoTrust Global CA is serial# 023456, expiration 5/20/2022. The old GeoTrust Global CA is serial# 12bbe6, expiration 8/20/2018.
At +5eF in the server cert chain being sent out, there is "12 bb e6". 05d0 - 25 b0 68 f9 de 08 5a f3-29 cc d4 92 00 03 81 30 %.h...Z.)......0 05e0 - 82 03 7d 30 82 02 e6 a0-03 02 01 02 02 03 12 bb ..}0............ 05f0 - e6 30 0d 06 09 2a 86 48-86 f7 0d 01 01 05 05 00 .0...*.H........ -- Donald J. dona...@4email.net On Tue, May 17, 2016, at 03:24 PM, Donald J. wrote: > John, > > I don't think you have the right GeoTrust certificate on your server. > > The server is sending out this cert chain: > Certificate chain > 0 s:/C=US/ST=New York/L=Armonk/O=INTERNATIONAL BUSINESS MACHINES > CORPORATION/CN=deliverycb-bld.dhe.ibm.com > i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 > 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > 3 s:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > > It should be sending out this cert chain: > 0 s:/C=US/ST=New York/L=Armonk/O=INTERNATIONAL BUSINESS MACHINES > CORPORATION/CN=deliverycb-bld.dhe.ibm.com > i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 > 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > i:/C=US/O=O=GeoTrust Inc./CN=GeoTrust Global CA > > GeoTrust issued a new "GeoTrust Global CA" cert several years ago > which does not chain to Equifax Secure Certificate Authority. > > Once you correct that, your IBM cert and the GeoTrust SSL CA - G3 cert > will both be sha2. It is not significant that the GeoTrust Global CA root > certificate is sha1. > > -- > Donald J. > dona...@4email.net > > On Tue, May 17, 2016, at 07:53 AM, John Eells wrote: > > So...suppose we were to do something like this*: > > > > - Added support for both SHA-2 (SHA-256) and 2048-bit RSA certificates.** > > - Put the package signing verification certificate where "anyone could > > get it" > > - Made the signing (certificate-based) check optional. > > - Continued to keep the integrity checking optional, whether based on > > SHA-2 or SHA-1. > > > > Would that meet the set of needs we've been talking about? > > > > * As usual, no promises. > > ** I think we have to keep the SHA-1 support because we create an > > incompatibility if we don't. > > > > Andrew Rowley wrote: > > > My further thoughts: > > > > > >> - Would a certificate-based signature do? > > >> - What requirements would you have for certificates? > > > The signature should use the same type of code signing certificates used > > > for other platforms. Any company delivering Windows software almost > > > certainly has a certificate already. There are various implementations, > > > e.g. Windows exe signing and Java jar signing. I'm pretty sure z/OS can > > > verify signatures on jars at least. Some thought would have to go into > > > how you attach a signature to a package and what you attach it to. > > > > > >> - Would you want signature verification to be optional? > > > Yes. For SMP/E it should be the default, probably at RECEIVE time but > > > able to be bypassed e.g. RECEIVE... BYPASS(SIGCHECK) . > > > Non-SMP/E is handicapped by the absence of a standard delivery format. > > > If you had a tool to deliver a set of non SMP/E datasets, the packaging > > > format should have an option to include a signature - perhaps with a > > > warning when extracting if unsigned and/or an option to force signature > > > checking. It depends on how useful the product would be inside a site - > > > you don't want to force customers to get their own certificate if they > > > decide a tool would be useful internally. > > > > > >> - If signature verification were to be optional, would it be > > >> acceptable to use the SHA-1 hash for integrity checking if the > > >> recipient chose not to verify the signature? Or, would it still be > > >> necessary to use a different algorithm? > > > > > > I'm not sure how useful it is. How likely is it that something be > > > corrupted in a situation where you can get a hash to verify but can't > > > verify a signature? > > > > > >> - Anything else to think about? > > > Lots, I'm sure! It's probably worth also looking at the implementation > > > of signed SMF data to see how they do it. > > > > > > Andrew Rowley > > > > > > > > > > > > -- > > John Eells > > IBM Poughkeepsie > > ee...@us.ibm.com > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > http://www.fastmail.com - A no graphics, no pop-ups email service > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- http://www.fastmail.com - A fast, anti-spam email service. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
