Hi, Did you see the email with the output?
[HPC Admin Host] [I am root!@uptus060-1:conf.d]#<mailto:root!@uptus060-1:conf.d]#> openssl s_client -connect hpc.gsk.com:443 CONNECTED(00000003) depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith Kline, OU = SRCA, CN = hpc.gsk.com, emailAddress = scientific_computing_supp...@gsk.com<mailto:scientific_computing_supp...@gsk.com> verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith Kline, OU = SRCA, CN = hpc.gsk.com, emailAddress = scientific_computing_supp...@gsk.com<mailto:scientific_computing_supp...@gsk.com> verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com<mailto:Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com> i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1 --- Server certificate -----BEGIN CERTIFICATE----- MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAAAAAFDzANBgkqhkiG9w0BAQsF ADBlMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIY29ycG5l dDExGTAXBgoJkiaJk/IsZAEZFgl3bXNlcnZpY2UxGTAXBgNVBAMTEEdTSyBJc3N1 aW5nIENBIDEwHhcNMjQwMzA4MTcyMDU1WhcNMjUwMzA4MTcyMDU1WjCBtTELMAkG A1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEZMBcGA1UEBxMQVXBwZXIg UHJvdmlkZW5jZTEaMBgGA1UEChMRR2xheG8gU21pdGggS2xpbmUxDTALBgNVBAsT BFNSQ0ExFDASBgNVBAMTC2hwYy5nc2suY29tMTMwMQYJKoZIhvcNAQkBFiRzY2ll bnRpZmljX2NvbXB1dGluZ19zdXBwb3J0QGdzay5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC1Cr+j9j5/739k+sHHiMDMvhprJmDHazw0UI1rPX7j W9wPg2kYHnP+jv33j7DB6vE/opCFVOgHTV3Lc7by3QBZAG142GPVSvu51k2syB+r AooW5a7onwaqZRKRSQX0NkHI4vSRHjVh9/0zxX6aPX6ygDyDKWOPslQ/71SFCyuZ /bgt/HMXeTP1WaT5u13lj5XtbRejx1WMu3HoRLguXZ6pBa5M5KNc9CaJJcnuTLzm 0152G1As1mkLJ2wm0PqzhXADoqXfnotBvZcSKov4+vYSSFB+7RUVLjdUVkRieDCK MBsGm+ufxUhWAxXnlC2b9NmM0XV7fr98V8WZD2D2sL4PAgMBAAGjggHEMIIBwDAv BgNVHREEKDAmggtocGMuZ3NrLmNvbYIXdXB0dXMwNjAtMS5jb3JwbmV0Mi5jb20w HQYDVR0OBBYEFAVcViHs7XlTuBk8aN7489VTL4pIMB8GA1UdIwQYMBaAFKvPJYEQ 0/UAImqrIU7r9upTKxjpMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9wa2kuZ3Nr LmNvbS9jZHAvR1NLJTIwSXNzdWluZyUyMENBJTIwMS5jcmwwcgYIKwYBBQUHAQEE ZjBkMD0GCCsGAQUFBzAChjFodHRwOi8vcGtpLmdzay5jb20vY2RwL0dTSyUyMElz c3VpbmclMjBDQSUyMDEuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vcGtpLmdzay5j b20vb2NzcDAOBgNVHQ8BAf8EBAMCBaAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC NxUI6vIrg/quQIX1kxyFkoFCheT+WYFUhq3CJ4KPsXwCAWQCAT8wHQYDVR0lBBYw FAYIKwYBBQUHAwEGCCsGAQUFBwMCMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUH AwEwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggIBAD0zCO/K/11ycaNA3scY SpT8Tqzc5wJToeC+EEyk+fCbwBaOfoPiDNLUC4jsG8kLtb1Z4XhBMa7eGmz3Xt58 ubVC5C4QW/AJI0v0oJU3atJoPk5h8iERGzolEHnbpvt1dLDpmwFzid6APzavixem v1FC0jmD2tk5W2HSaMCZ8Qbt8B9uSwyknxLwjc4oyMxs1Oq1Jtsv8HCzC4Bi9yd6 RYbB4uNAvULBSK5RoIjgsONfE42fnJKPCS1TBPWkjlROlmhyvi76NNoPl4GlS+eM pv9FB+Q7xcYTrfoygvEy6lvPCgQ3AqFcVmbQg5dEBMthPAymBHAdQHkjbKfVJd5X W8CFmsZ7pD8nmj5lfzT4SpkiMj59U0bj2e8FfLWQybtiGCGFO9M/nZdOHQndxHua O8bJzWs4rCy9hw+iOHZEUEe06m+mc+rLPN7DTO1rQOAk/BdakIauQyMTh5oYQ2mM us+7YUwZrNidZv9xfAJZc+zmnaumoGIbxkKChSfwhtb5L8uFnfQc6XDNaYUVKvwi XV9OQgiymXkGAp8Ai5eVv881BirqQkHyAtbUdpazUF5jlxreowp24NSAa/rWLa6p RKqS9aPC2lOfR2Kysv1SvJgst1OvtckqKsdlunGxRUH5gInwn7gzzmovCeWiD3+F GzKWlw6feJiNivlqBH1QwP39 -----END CERTIFICATE----- subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com<mailto:Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com> issuer=/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1 --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 2341 bytes and written 427 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: F8C2904FEE4CA89D0F03B21E4D8E16B120419D3F0737265AAC27452DD5BAD62E Session-ID-ctx: Master-Key: 4D6D3D158228C520B36FF399795D8B847ADF21E2559CDB3EC0CDE8E8AF322B1397B9531598C5CA1215385F6CE8113248 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - 33 fa b8 44 6b 0f fe 61-e5 14 06 66 19 9d 0e 73 3..Dk..a...f...s 0010 - 8f 06 54 21 20 97 7d ac-2c c4 12 91 c8 c0 c7 7f ..T! .}.,....... 0020 - 09 8a c8 13 0a 58 fc 16-e2 f3 96 67 c6 d6 d5 58 .....X.....g...X 0030 - ab 60 47 fc 66 22 17 8b-04 73 fd 2d a5 62 c4 35 .`G.f"...s.-.b.5 0040 - e8 dc 3a a9 e6 37 ba 2a-ea 05 0d ea fb 5a 01 80 ..:..7.*.....Z.. 0050 - 88 9e 6a 5d 7b ae 21 8f-89 32 af ae 0c 52 20 27 ..j]{.!..2...R ' 0060 - 2f 1b 8e ae 18 82 54 c0-ee e4 b9 bb 1e 71 be db /.....T......q.. 0070 - c3 0e 36 9f 0b ce a4 2e-be dc 1d 3f 10 01 08 71 ..6........?...q 0080 - ae 74 b1 d4 1f ce 46 a3-94 54 93 ad 67 4a 72 15 .t....F..T..gJr. 0090 - 93 5a 46 0c 84 35 f2 b6-7e 2d 7a 07 b5 7a ca 47 .ZF..5..~-z..z.G 00a0 - 88 8f 1a fa 78 cc 49 26-12 26 54 0d 27 5d f6 a3 ....x.I&.&T.'].. 00b0 - 43 d1 2b 7d c6 6f b9 19-32 a8 56 35 9a 1c 31 97 C.+}.o..2.V5..1. Start Time: 1711376647 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- :q! HTTP/1.1 400 Bad Request Date: Mon, 25 Mar 2024 14:24:13 GMT Server: Apache Content-Length: 226 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> </head><body> <h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> </p> </body></html> read:errno=0 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 12:01 PM To: Stanley Gilliam <stanley.x.gill...@gsk.com> Cc: noloa...@gmail.com; users@subversion.apache.org Subject: Re: SVN does not trust cert Den mån 25 mars 2024 kl 16: 34 skrev Stanley Gilliam <stanley. x. gilliam@ 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 Den mån 25 mars 2024 kl 16:34 skrev Stanley Gilliam <stanley.x.gill...@gsk.com<mailto: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<http://hpc.gsk.com:443/> -servername hpc.gsk.com<http://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<mailto:daniel.l.sahlb...@gmail.com>> Sent: Monday, March 25, 2024 11:17 AM To: noloa...@gmail.com<mailto:noloa...@gmail.com> Cc: Stanley Gilliam <stanley.x.gill...@gsk.com<mailto:stanley.x.gill...@gsk.com>>; users@subversion.apache.org<mailto: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. 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.
