Re: SVN does not trust cert

Den mån 25 mars 2024 kl 16:34 skrev Stanley Gilliam <
[email protected]>:

> Hello,
>
>
>
> So we use appview to update our certificates and our cert team confirmed
> that the cert was updated correctly. Is there another way to possibly
> verify this. There may also be something to the second option, I am on a
> linux RH OS. Is there a way someone could jump on a short call with us?
>

What if you run the same command as Jeffrey already tries, ie:

$ openssl s_client -connect hpc.gsk.com:443 -servername hpc.gsk.com

(I had to Ctrl-D out of the above command). I'm not familiar with openssl
debugging but there seems to be a lot of useful information on the
certificate chain. Verify that all the intermediary certificates are
available and that the root certificate is trusted by your client.

Kind regards,
Daniel





>
>
> Stanley Gilliam
>
> System Administrator
>
> GSK
>
> 14200 Shady Grove Rd
>
> Rockville, MD 20850
>
> 678-548-7768
>
>
>
> *From:* Daniel Sahlberg <[email protected]>
> *Sent:* Monday, March 25, 2024 11:17 AM
> *To:* [email protected]
> *Cc:* Stanley Gilliam <[email protected]>;
> [email protected]
> *Subject:* Re: SVN does not trust cert
>
>
>
> Den mån 25 mars 2024 kl 15: 19 skrev Jeffrey Walton <noloader@ gmail.
> com>: On Mon, Mar 25, 2024 at 9: 54 AM Stanley Gilliam via users <users@
> subversion. apache. org> wrote: > > I am a system admin for
> GlaxoSmithKline. We are currently
>
> Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton <[email protected]>:
>
> On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
> <[email protected]> wrote:
> >
> > I am a system admin for GlaxoSmithKline. We are currently having issues
> getting our svn instance to authenticate. This all happened after the cert
> was updated. We are currently getting the message :
> >
> > svn: E175002: OPTIONS of 'https://hpc.gsk.com/xxx/xxx/etc': Server
> certificate verification failed: issuer is not trusted (
> https://hpc.gsk.com)
> >
> > The cert was updated correctly we believe because the website works.
> >
> > is there anybody that may be able to help?
>
> DNS seems to be a problem:
>
> $ openssl s_client -connect hpc.gsk.com:443 -servername hpc.gsk.com
> 40D7F6E4F1710000:error:10080002:BIO routines:BIO_lookup_ex:system
> lib:../crypto/bio/bio_addr.c:738:Name or service not known
> connect:errno=22
>
> And:
>
> $ nslookup hpc.gsk.com
> Server:         127.0.0.53
> Address:        127.0.0.53#53
>
> ** server can't find hpc.gsk.com: NXDOMAIN
>
> You should add a DNS entry for the host 'hpc'. Then, rerun the experiment.
>
>
>
> It might be that the hpc.gsk.com domain is only available on an internal
> network (ie, on an internal DNS server). If there was a missing DNS entry
> you should get an error message similar to this:
>
>
>
> $ svn ls https://hpc.gsk.com
>
> svn: E170013: Unable to connect to a repository at URL '
> https://hpc.gsk.com'
>
> svn: E670002: Name or service not known
>
> $
>
>
>
> (The missing DNS entry makes it more difficult for someone outside of the
> company to help in debugging of course!).
>
>
>
> "issuer is not trusted" sounds to me like it is a self-signed certificate
> or that the certificate is signed by a root that isn't trusted by the
> client. Can you verify that the client really trust the issuer of the
> certificate?
>
>
>
> Another potential explanation (although not supported by the available
> evidence) is that there is a mismatch between the cipher of the new
> certificate compared to what OpenSSL on the client is supporting.
>
>
>
> Which platform are you on and what are the versions of Subversion and the
> linked OpenSSL library?
>
>
>
> Kind regards,
>
> Daniel
>
>
>
> *GSK monitors email communications sent to and from GSK in order to
> protect GSK, our employees, customers, suppliers and business partners,
> from cyber threats and loss of GSK Information. GSK monitoring is conducted
> with appropriate confidentiality controls and in accordance with local laws
> and after appropriate consultation.*
>