Re: SVN does not trust cert

2024-03-25 Thread Jeffrey Walton 
On Mon, Mar 25, 2024 at 1:04 PM Stanley Gilliam
 wrote:
>
> If I am understanding correctly, we need to add something like:
> 1 s:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
>   i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Root CA
>
> to which config file? Apologies I did not set up the server so I'm learning 
> this as we go.

Assuming you are using Apache... Here's what one of ours looks like
for cryptopp.com web server (we don't run SVN on this server, but it
illustrates a TLS configuration). And we are using Ubuntu, not CentOS
or Red Hat (we had to get away from that antique software RH
provides).

>From 
>:

SSLCertificateFile /etc/ssl/private/cryptopp-com.cert.pem
SSLCertificateKeyFile /etc/ssl/private/cryptopp-com.key.pem
SSLCertificateChainFile /etc/ssl/private/cryptopp-com.chain.pem

The files are what you would expect.

   * SSLCertificateFile is the web server's certificate
   * SSLCertificateKeyFile is the private key for the public key in
the certificate
   * SSLCertificateChainFile is the collection of intermediate
certificates for chain validation

Apache knows what to do with them.

Here is the chain file. Notice we do not include the Let's Encrypt
Root CA since clients are expected to have it and trust it:

# cat /etc/ssl/private/cryptopp-com.chain.pem

# Let's Encrypt Authority R3
-BEGIN CERTIFICATE-
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-END CERTIFICATE-

You can use the same openssl commands to finger our web server (or any
other well configured server). In fact, once I change a configuration
(like with the quarterly end entity certificate update), I test using
SSL Labs: 
.

Jeff

Re: SVN does not trust cert

2024-03-25 Thread Stanley Gilliam via users 
Would it be OpenSSL.conf?

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Stanley Gilliam 
Sent: Monday, March 25, 2024 1:04:11 PM
To: noloa...@gmail.com 
Cc: Daniel Sahlberg ; users@subversion.apache.org 

Subject: RE: SVN does not trust cert

Hi Jeff,

If I am understanding correctly, we need to add something like:
1 s:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
  i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Root CA

to which config file? Apologies I did not set up the server so I'm learning 
this as we go.


Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

-Original Message-
From: Jeffrey Walton 
Sent: Monday, March 25, 2024 12:34 PM
To: Stanley Gilliam 
Cc: Daniel Sahlberg ; users@subversion.apache.org
Subject: Re: SVN does not trust cert

On Mon, Mar 25, 2024 at 12:26 PM Stanley Gilliam  
wrote:
>
> Here is the output:
>
> [I am root!@uptus060-1:private]# echo "$cert" | openssl x509 -inform
> PEM -text -noout unable to load certificate
> 139671613519760:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
>
>
> [I am root!@uptus060-1:private]#  openssl s_client -connect
> hpc.gsk.com:443 -servername hpc.gsk.com -showcerts
> CONNECTED(0003)
> 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
> 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
> 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
>i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1 -BEGIN
> CERTIFICATE-
> MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
> 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-
> ---
> Server certificate
> subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith
> Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_support
> @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
> -

RE: SVN does not trust cert

2024-03-25 Thread Stanley Gilliam via users 
Hi Jeff,

If I am understanding correctly, we need to add something like:
1 s:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
  i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Root CA

to which config file? Apologies I did not set up the server so I'm learning 
this as we go.


Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

-Original Message-
From: Jeffrey Walton 
Sent: Monday, March 25, 2024 12:34 PM
To: Stanley Gilliam 
Cc: Daniel Sahlberg ; users@subversion.apache.org
Subject: Re: SVN does not trust cert

On Mon, Mar 25, 2024 at 12:26 PM Stanley Gilliam  
wrote:
>
> Here is the output:
>
> [I am root!@uptus060-1:private]# echo "$cert" | openssl x509 -inform
> PEM -text -noout unable to load certificate
> 139671613519760:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
>
>
> [I am root!@uptus060-1:private]#  openssl s_client -connect
> hpc.gsk.com:443 -servername hpc.gsk.com -showcerts
> CONNECTED(0003)
> 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
> 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
> 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
>i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1 -BEGIN
> CERTIFICATE-
> MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
> 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-
> ---
> Server certificate
> subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith
> Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_support
> @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 2361 bytes and written 447 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public
> key is 2048 bit Secure Renegotiation IS supported
> Compression: NONE
>

Re: SVN does not trust cert

2024-03-25 Thread Jeffrey Walton 
On Mon, Mar 25, 2024 at 12:26 PM Stanley Gilliam
 wrote:
>
> Here is the output:
>
> [I am root!@uptus060-1:private]# echo "$cert" | openssl x509 -inform PEM 
> -text -noout
> unable to load certificate
> 139671613519760:error:0906D06C:PEM routines:PEM_read_bio:no start 
> line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
>
>
> [I am root!@uptus060-1:private]#  openssl s_client -connect hpc.gsk.com:443 
> -servername hpc.gsk.com -showcerts
> CONNECTED(0003)
> 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
> 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
> 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
>i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
> -BEGIN CERTIFICATE-
> MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
> 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-
> ---
> Server 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
> 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 2361 bytes and written 447 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: 
> 4A9C3A7A8D91D5BE107F514BD64009F30D71C338D3C0E11AD6F8F2BBA256BDFA
> Session-ID-ctx:
> Master-Key: 
> 4B6426694B33A96B96BD3B382D7266826F1FC80C0B4857A9953AE969E6AB903B44739603E06D1933E269DCFA5D30CFD9
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> TLS session ticket lifetime hint: 7200 (seconds)
> TLS session ticket:
>  - 25 98 6a 95 45 08 1d 16-50 d9 fa 27 98 8f a3 9f   %.j.E...P..'
> 0010 - 5e 8f e6 ca a5 05 be ea-e5 e7 00 8d da 8f 10 0a   ^...
> 0020 - 0c d2 c2 94 ca eb 06 74-46 a1 00 5f 97 b3 aa f1   ...tF.._
> 0030 - b7 2a a3 19 84 67 72 5d-13 f9 9f a4 86 4f 98 13   .*...gr].O..
> 0040 - 01 37

RE: SVN does not trust cert

2024-03-25 Thread Stanley Gilliam via users 
 35 73-6f 35 cd 09 ce 47 cc af   .#.n..5so5...G..
0080 - 19 71 0e 5f c5 63 18 a9-d6 b8 d8 23 85 e3 d9 75   .q._.c.#...u
0090 - 17 09 46 ac 5a 7b 03 01-55 95 19 80 81 f3 11 19   ..F.Z{..U...
00a0 - e5 e2 03 cc cd 8b 3c 63-8c fb 91 99 4c 98 9c 64   ..
Sent: Monday, March 25, 2024 12:16 PM
To: Stanley Gilliam 
Cc: Daniel Sahlberg ; users@subversion.apache.org
Subject: Re: SVN does not trust cert

On Mon, Mar 25, 2024 at 11:55 AM Stanley Gilliam  
wrote:
>
> I apologize for the miscommunication. Here is the output from the openssl 
> command:
>
> [I am root!@uptus060-1:conf.d]# openssl s_client -connect
> hpc.gsk.com:443

You should use -servername here. It triggers Server Name Indication (SNI).

> CONNECTED(0003)
> 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
> 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
> 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
>i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
> 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_support
> @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: 
> 4D6D3D158228C520B36FF399795D8B847ADF21E2559CDB3EC0CDE8E8AF322B1397B9531598C5CA1215385F6CE811324

Re: SVN does not trust cert

2024-03-25 Thread Jeffrey Walton 
On Mon, Mar 25, 2024 at 12:01 PM Daniel Sahlberg
 wrote:
>
> Den mån 25 mars 2024 kl 16:34 skrev Stanley Gilliam 
> :
>>
>> 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.

CRTL+D is normal in this situation. OpenSSL is used to create the
secure channel to the application. However, the application (a web
server) is waiting for a command, like GET or POST.

You can sidestep it with something like:

echo -e 'GET / HTTP1.1\r\n\r\n' | openssl s_client ...

That sends a command to the web server. The web server will provide a
response, and then close the connection.

Jeff

RE: SVN does not trust cert

2024-03-25 Thread Stanley Gilliam via users 
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   .tF..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&.']..
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



400 Bad Request

Bad Request
Your browser sent a request that this server could not understand.


read:errno=0

Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

From: Daniel Sahlberg 
Sent: Monday, March 25, 2024 12:01 PM
To: Stanley Gilliam 
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 : 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 
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 
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 
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 : On 
Mon, Mar 25, 2024 at 9: 54 AM Stanley Gilliam via users  wrote: > > I am a system admin for GlaxoSmithKline. We are 
currently
Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton 
mailto:noloa...@gmail.com>>:
On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
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>
40D7F6E4F171: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 certific

Re: SVN does not trust cert

2024-03-25 Thread Jeffrey Walton 
On Mon, Mar 25, 2024 at 11:55 AM Stanley Gilliam
 wrote:
>
> I apologize for the miscommunication. Here is the output from the openssl 
> command:
>
> [I am root!@uptus060-1:conf.d]# openssl s_client -connect hpc.gsk.com:443

You should use -servername here. It triggers Server Name Indication (SNI).

> CONNECTED(0003)
> 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
> 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
> 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
>i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
> 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
> 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:
>  - 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 '

RE: SVN does not trust cert

2024-03-25 Thread Stanley Gilliam via users 
Adding @Jung Yi

Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

-Original Message-
From: Stanley Gilliam 
Sent: Monday, March 25, 2024 11:55 AM
To: noloa...@gmail.com
Cc: Daniel Sahlberg ; users@subversion.apache.org
Subject: RE: SVN does not trust cert

Ok,

I apologize for the miscommunication. Here is the output from the openssl 
command:

[I am root!@uptus060-1:conf.d]# openssl s_client -connect hpc.gsk.com:443
CONNECTED(0003)
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
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
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
   i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
---
Server certificate
-BEGIN CERTIFICATE-
MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
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
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:
 - 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 '

RE: SVN does not trust cert

2024-03-25 Thread Stanley Gilliam via users 
Centos Linux 7.9

Adding @Jung Yi<mailto:jung.j...@gsk.com>

Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

From: Daniel Sahlberg 
Sent: Monday, March 25, 2024 11:17 AM
To: noloa...@gmail.com
Cc: Stanley Gilliam ; users@subversion.apache.org
Subject: Re: SVN does not trust cert

Den mån 25 mars 2024 kl 15: 19 skrev Jeffrey Walton : On 
Mon, Mar 25, 2024 at 9: 54 AM Stanley Gilliam via users  wrote: > > I am a system admin for GlaxoSmithKline. We are 
currently

Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton 
mailto:noloa...@gmail.com>>:
On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
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>
40D7F6E4F171: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.

RE: SVN does not trust cert

2024-03-25 Thread Stanley Gilliam via users 
 00a0 - 88 8f 1a fa 78 cc 49 26-12 26 54 0d 27 5d f6 a3   x.I&.']..
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



400 Bad Request

Bad Request
Your browser sent a request that this server could not understand.


read:errno=0


I updated the cert here :


[I am root!@uptus060-1:~]# cd /etc/pki/tls/certs/
[HPC Admin Host]
[I am root!@uptus060-1:certs]# ll
total 44
-rw-r--r-- 1 root root 2290 Mar 25 08:53 ca.2048.crt
lrwxrwxrwx 1 root root   49 Jul 11  2020 ca-bundle.crt -> 
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
lrwxrwxrwx 1 root root   55 Jul 11  2020 ca-bundle.trust.crt -> 
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt

lrwxrwxrwx 1 root root   32 Mar 25 08:54 com.gsk.hpc-2048.crt -> 
uptus060-1.corpnet2.com.crt.2024


-rw-r- 1 root root 1688 Mar 15  2018 com.gsk.hpc-2048.crt~
-rw--- 1 root root 1476 Nov 19  2018 localhost.crt
-rwxr-xr-x 1 root root  610 Aug  8  2019 make-dummy-cert
-rw-r--r-- 1 root root 2516 Aug  8  2019 Makefile
-rwxr-xr-x 1 root root  829 Aug  8  2019 renew-dummy-cert
-rw-r--r-- 1 root root 1497 Apr 25  2021 rsyslog-ca.pem
-rw-r--r-- 1 root root 1472 Apr 25  2021 rsyslog-cert.pem
-rw-r--r-- 1 root root 2290 Mar 25 08:54 uptus060-1.corpnet2.com.crt.2024

Using the key here :
(private.key)

[I am root!@uptus060-1:private]# ll
total 28
-rw-r--r-- 1 root root 1200 Mar 19 10:24 com.corpnet2.uptus060-1.csr
-rwx-- 1 root root 3160 Mar 15  2018 com.gsk.hpc-2048.pem
-rw--- 1 root root 1679 Mar  8  2018 com.gsk.hpc.key.selfsigned
-rw--- 1 root root 1675 Mar  8 11:50 localhost.key
-rw-r--r-- 1 root root 1679 Mar  8 12:31 private.key
-rw--- 1 root root 5816 Apr 25  2021 rsyslog-key.pem

Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

-Original Message-
From: Jeffrey Walton 
Sent: Monday, March 25, 2024 11:42 AM
To: Stanley Gilliam 
Cc: Daniel Sahlberg ; users@subversion.apache.org
Subject: Re: SVN does not trust cert

On Mon, Mar 25, 2024 at 11:34 AM Stanley Gilliam  
wrote:
>
> 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?

We don't know what the certificate chain or the end entity certificate looks 
like. You have not described it, and you have not posted the output of the 
openssl command. For me, it is not clear what has been done to the server 
(replaced an end entity certificate?) and what has been done to a typical 
client (nothing because the PKI has not
changed?)

At this point, all folks can do is guess.

Jeff
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.

Re: SVN does not trust cert

2024-03-25 Thread Daniel Sahlberg 
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 
> *Sent:* Monday, March 25, 2024 11:17 AM
> *To:* noloa...@gmail.com
> *Cc:* Stanley Gilliam ;
> users@subversion.apache.org
> *Subject:* Re: SVN does not trust cert
>
>
>
> Den mån 25 mars 2024 kl 15: 19 skrev Jeffrey Walton  com>: On Mon, Mar 25, 2024 at 9: 54 AM Stanley Gilliam via 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 :
>
> On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
>  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
> 40D7F6E4F171: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.*
>

RE: SVN does not trust cert

2024-03-25 Thread Stanley Gilliam via users 
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 
Sent: Monday, March 25, 2024 11:17 AM
To: noloa...@gmail.com
Cc: Stanley Gilliam ; users@subversion.apache.org
Subject: Re: SVN does not trust cert

Den mån 25 mars 2024 kl 15: 19 skrev Jeffrey Walton : On 
Mon, Mar 25, 2024 at 9: 54 AM Stanley Gilliam via users  wrote: > > I am a system admin for GlaxoSmithKline. We are 
currently

Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton 
mailto:noloa...@gmail.com>>:
On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
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>
40D7F6E4F171: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.

Re: SVN does not trust cert

2024-03-25 Thread Jeffrey Walton 
On Mon, Mar 25, 2024 at 11:34 AM Stanley Gilliam
 wrote:
>
> 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?

We don't know what the certificate chain or the end entity certificate
looks like. You have not described it, and you have not posted the
output of the openssl command. For me, it is not clear what has been
done to the server (replaced an end entity certificate?) and what has
been done to a typical client (nothing because the PKI has not
changed?)

At this point, all folks can do is guess.

Jeff

Re: SVN does not trust cert

2024-03-25 Thread Daniel Sahlberg 
Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton :

> On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
>  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
> 40D7F6E4F171: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

Re: SVN does not trust cert

2024-03-25 Thread Jeffrey Walton 
On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
 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
40D7F6E4F171: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.

Jeff

SVN does not trust cert

2024-03-25 Thread Stanley Gilliam via users 
Hi,

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?

Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768


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.