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?
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<mailto:noloa...@gmail.com>>: On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users <users@subversion.apache.org<mailto: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<http://hpc.gsk.com:443> -servername hpc.gsk.com<http://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<http://hpc.gsk.com> Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find hpc.gsk.com<http://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<http://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.
