Den mån 25 mars 2024 kl 16:34 skrev Stanley Gilliam < stanley.x.gill...@gsk.com>:
> 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 <daniel.l.sahlb...@gmail.com> > *Sent:* Monday, March 25, 2024 11:17 AM > *To:* noloa...@gmail.com > *Cc:* Stanley Gilliam <stanley.x.gill...@gsk.com>; > users@subversion.apache.org > *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 <noloa...@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 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.* >
