Yes. When I go to port 443 I also see the correct chain: openssl s_client -debug -connect dispby-117.boulder.ibm.com:443 -state
SSL_connect:SSLv3 read finished A --- 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=GeoTrust Inc./CN=GeoTrust Global CA When I go to port 21, I see: openssl s_client -debug -connect dispby-117.boulder.ibm.com:21 -state -starttls ftp SSL_connect:SSLv3 read finished A --- 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 -- Donald J. [email protected] On Tue, May 17, 2016, at 05:08 PM, Andrew Rowley wrote: > On 18/05/2016 0:53, John Eells wrote: > > - 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. > > From Donald's post it sounds like the original problem might be the > FTPS/HTTPS certificates, not the SHA1 verification of data already > transmitted over a secure channel. This makes more sense from an audit > point of view, and I think someone suggested a firewall was complaining > - it would have no awareness of what was done with the data after > transmission. In that case fixing the certificate is the simple solution. > > I just checked deliverycb-bld.dhe.ibm.com and I see a different > certificate chain to Donald - I see the 023456 GeoTrust Global CA. Is it > possible that it resolves to multiple hosts with different certificates > e.g. in different countries, or that it has just been fixed? > > On the question of package signing, I would suggest that it should be > done using the usual methods which means that you don't need to put a > certificate where anyone can get it. > > z/OS should have the common root CAs installed with the operating system > (if it doesn't already). Then (as I understand it) the signed > certificate is included with the signature. To verify it you then follow > the chain of signed certificates until you get to one signed by the root > CA that you already have. > > This means that you can verify the origin of something without knowing > the correct place to get that particular public key. > > Andrew Rowley > > > -- > Andrew Rowley > Black Hill Software > +61 413 302 386 > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- http://www.fastmail.com - Same, same, but different... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
