[pca] back and annoyed

[Don O'Malley]

HI Martin,

Here's some internal analysis of the certificate issues (it's pretty 
much what you have below)...

Thought it was worth passing on all the same.

Best,
-Don


I was able to get the --ca-certificate switch to work using a file I 
created called cacerts.pem and then subsequently adding the 
--ca-certificate=<path_to_file>/cacerts.pem to the regular wget command 
line.
The cacerts.pem that I created is a concatenation of the two CA certs 
that are required, namely:

CN=GTE CyberTrust Global Root
CN=VeriSign Class 3 Secure Server CA - G2

As mentioned, it is also possible to just use the --no-check-certificate 
option, though that may be of concern to some customers.

Thanks,
Scott

> I have begun to dig a bit deeper on the client side to see what is 
> going on. Both domains, getupdates2.sun.com and a248.e.akamai.net, are 
> signed by trusted Certificate Authorities. Verisign for ours and GTE 
> Cybertrust for the case of Akamai. The original getupdates1.sun.com is 
> "self-signed" in the chain because there is an intermediary 
> certificate that is used to directly sign the cert which is owned by 
> SunPKI. That is a requirement of Sun security and we have only until 
> the end of this calendar year before the exemption for 
> getupdates2.sun.com expires and we are required to replace the current 
> Verisign-direct cert with one that chains up to Verisign via the 
> SunPKI intermediate.
>
> From the wget manual, I see that the Certificate Authorities are 
> defined during the OpenSSL installation. What is not mentioned there 
> (or in the OpenSSL documentation) is that there is no default 
> ca-certificate file, in other words no bundle. So it doesn't matter 
> what ssl site you attempt to go to nor from whom their certificate is 
> issued. Unless you take specific action during the installation of 
> OpenSSL or in the command line wget invocation, you won't trust the 
> SSL cert.
>
> Here is the info from wget manual 
> (http://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_0029-Options.html) 
>
>
> ‘--ca-certificate=file’
> Use file as the file with the bundle of certificate authorities (“CA”) 
> to verify the peers. The certificates must be in PEM format.
>
> Without this option Wget looks for CA certificates at the 
> system-specified locations, chosen at OpenSSL installation time.
>
>
> ‘--ca-directory=directory’
> Specifies directory containing CA certificates in PEM format. Each 
> file contains one CA certificate, and the file name is based on a hash 
> value derived from the certificate. This is achieved by processing a 
> certificate directory with the c_rehash utility supplied with OpenSSL. 
> Using ‘--ca-directory’ is more efficient than ‘--ca-certificate’ when 
> many certificates are installed because it allows Wget to fetch 
> certificates on demand.
>
> Without this option Wget looks for CA certificates at the 
> system-specified locations, chosen at OpenSSL installation time.
>
> I'm looking now on an S10 box we have in the lab to see if I can find 
> a pre-existing cacerts file that is in the proper format and that 
> includes the necessary CA references so that we can plug that into the 
> wget command line. I'll report back as I learn more. For the interim, 
> here is an interesting post I found on the subject. 
> http://curl.haxx.se/mail/archive-2003-07/0036.html
>
> Scott 


Martin Paul wrote:
> Don O'Malley wrote:
>> I have confirmed that the patchdiag.xerf will remain on SunSolve.
>
> Thanks. I guess I will make pca use HTTPS for the xref file when wget 
> supports it, and HTTP if it doesn't (as a fallback) and deprecate 
> --ssprot (as soon as I know what's going to happen with the READMEs).
>
>> I have version 1.10.2 installed and always use "--no-check-certificate"
> > with wget. I'm not seeing any issue with this.
>
> What I meant is that it shouldn't be necessary to use 
> --no-check-certificate with wget at all :)
>
> Somebody may correct me, but the main reason to use HTTPS over HTTP 
> (esp. when downloading patches) is the server authentication, so you 
> can be sure that you are getting the patches from Sun and not from 
> some rogue server. By not checking the certificate this is defeated. 
> The wget manual says:
>
> Only use this option if you are otherwise convinced of the site's
> authenticity, or if you really don't care about the validity of its
> certificate.
>
> Now sunsolve.sun.com *does* have a certificate which is signed by one 
> of the usual certificate authorities. All browsers include these root 
> CA certs, so verification works fine there. openssl/wget on Linux 
> distributions come with the root CA certs by default, too.
>
> In pca I'm using a workaround - I include the necessary root CA cert 
> in pca itself, and point wget at it with its --ca-certificate option. 
> That's why I don't need to use --no-check-certificate.
>
> Of course there's a second advantage with using HTTPS - encryption. 
> But as the files which are transferred (patches) aren't really secret 
> - anyone with a support contract can access them - it's less important 
> than authentication.
>
> Martin.
>