Running:
svn checkout https://hostname
gives:
svn: E170013: Unable to connect to a repository at URL 'http://hostname'
svn: E120171: Error running context: An error occurred during SSL communication
Running this command:
curl -v --insecure https://hostname
gives
* Trying 10.181.203.1:2795...
* Connected to 10.181.203.1 (10.181.203.1) port 2795 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.0 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.0 (IN), TLS header, Certificate Status (22):
* TLSv1.0 (IN), TLS handshake, Certificate (11):
* TLSv1.0 (IN), TLS header, Certificate Status (22):
* TLSv1.0 (IN), TLS handshake, Server key exchange (12):
* TLSv1.0 (OUT), TLS header, Unknown (21):
* TLSv1.0 (OUT), TLS alert, internal error (592):
* error:0A0C0103:SSL routines::internal error
* Closing connection 0
curl: (35) error:0A0C0103:SSL routines::internal error
I tried to fix openssl config with "MinProtocol = TLSv1" but that doesn't help.
Help please
Ubuntu 22.04 LTS
Here is a solution to resolve Error:
curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation disabled
https://github.com/Kong/insomnia/issues/4543#issuecomment-1126771807
And then , a new Error :
curl: (35) error:0A000102:SSL routines::unsupported protocol
Just use old method like this:
https://stackoverflow.com/a/61568390/19289721
Final error like yours:
curl: (35) error:0A0C0103:SSL routines::internal error
Found the changelog in openssl.org
The security strength of SHA1 and MD5 based signatures in TLS has been reduced.
This results in SSL 3, TLS 1.0, TLS 1.1 and DTLS 1.0 no longer working at the default security level of 1 and instead requires security level 0. The security level can be changed either using the cipher string with #SECLEVEL, or calling SSL_CTX_set_security_level(3). This also means that where the signature algorithms extension is missing from a ClientHello then the handshake will fail in TLS 1.2 at security level 1. This is because, although this extension is optional, failing to provide one means that OpenSSL will fallback to a default set of signature algorithms. This default set requires the availability of SHA1.
https://www.openssl.org/docs/man3.0/man7/migration_guide.html
So...Change #SECLEVEL=1 to #SECLEVEL=0
All be fine!
<html><body><h1>It works!</h1></body></html>
Full openssl.cnf diff is :
54c54,67
< providers = provider_sect
---
> # providers = provider_sect # commented out
>
> # added
> ssl_conf = ssl_sect
>
> # added
> [ssl_sect]
> system_default = system_default_sect
>
> # added
> [system_default_sect]
> Options = UnsafeLegacyRenegotiation
> MinProtocol = TLSv1
> CipherString = DEFAULT:#SECLEVEL=0
Copy your openssl configure file to any path like /path/to/openssl_tls1.cnf
Apply the patch, and add setting OPENSSL_CONF=/path/to/openssl_tls1.cnf
NOTE:
UnsafeLegacyRenegotiation: permits the use of unsafe legacy renegotiation. Equivalent to SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION.
MinProtocol
This sets the minimum supported SSL, TLS or DTLS version.
Currently supported protocol values are SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1 and DTLSv1.2. The SSL and TLS bounds apply only to TLS-based contexts, while the DTLS bounds apply only to DTLS-based contexts. The command can be repeated with one instance setting a TLS bound, and the other setting a DTLS bound. The value None applies to both types of contexts and disables the limits.
The cipher string #SECLEVEL=n can be used at any point to set the security level to n, which should be a number between zero and five, inclusive.See SSL_CTX_set_security_level for a description of what each level means.
DEFAULT CALLBACK BEHAVIOUR
If an application doesn't set its own security callback the default callback is used. It is intended to provide sane defaults. The meaning of each level is described below.
Level 0
Everything is permitted. This retains compatibility with previous versions of OpenSSL.
Level 1
The security level corresponds to a minimum of 80 bits of security. Any parameters offering below 80 bits of security are excluded. As a result RSA, DSA and DH keys shorter than 1024 bits and ECC keys shorter than 160 bits are prohibited. All export cipher suites are prohibited since they all offer less than 80 bits of security. SSL version 2 is prohibited. Any cipher suite using MD5 for the MAC is also prohibited.
Level 2
Security level set to 112 bits of security. As a result RSA, DSA and DH keys shorter than 2048 bits and ECC keys shorter than 224 bits are prohibited. In addition to the level 1 exclusions any cipher suite using RC4 is also prohibited. SSL version 3 is also not allowed. Compression is disabled.
Try with --trust-server-cert , with an understanding that you are bypassing a certificate check.
SVN doc: https://svnbook.red-bean.com
Related
I have a wildcard Certificate issued by letsencrypt (*.stg.foo.com)
Two .NET Core Applications in a docker container running behind a Nginx are listening to admin.stg.foo.com and srv.stg.foo.com
This Setup so far seems to work as expected. I can access my containers through a browser and the certificate is valid.
If I run a curl from a container to another it works as expected
curl https://admin.stg.foo.com/ -v
ALPN, offering h2
...
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
TLSv1.3 (OUT), TLS handshake, Client hello (1):
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS handshake, Certificate (11):
TLSv1.2 (IN), TLS handshake, Server key exchange (12):
TLSv1.2 (IN), TLS handshake, Server finished (14):
TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
TLSv1.2 (OUT), TLS handshake, Finished (20):
TLSv1.2 (IN), TLS handshake, Finished (20):
SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
ALPN, server accepted to use h2
Server certificate:
subject: CN=.stg.foo.com
start date: Jul 8 04:50:10 2020 GMT
expire date: Oct 6 04:50:10 2020 GMT
subjectAltName: host "admin.stg.foo.com" matched cert's "*.stg.foo.com"
issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
SSL certificate verify ok.
If I try to do the same request from a docker container with a HttpClient the certificate validation fails with:
The remote certificate is invalid according to the validation procedure:
Unhandled exception. System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
at System.Net.Security.SslStream.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, ExceptionDispatchInfo exception)
at System.Net.Security.SslStream.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
Test Code:
using (HttpClient client = new HttpClient())
{
var result = await client.GetAsync("https://admin.stg.foo.com/.well-known/openid-configuration");
Console.WriteLine(await result.Content.ReadAsStringAsync());
result.EnsureSuccessStatusCode();
}
The same request running on a Windows Machine works.
Does .NET use another folder for certs than curl (/etc/ssl/certs)?
Are there more logs to debug .Net Core Cert Errors?
Setup:
.NET Core 3.1.5
Ubuntu 20.04 LTS
Thanks for Help
Edit:
Found Similar Issue: The remote certificate is invalid according to the validation procedure
$ stack setup -v
Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd i386 hpack-0.17.0
2017-05-26 07:40:44.945473: [debug] Checking for project config at: C:\development\repos\eta\stack.yaml
#(Stack\Config.hs:935:9)
2017-05-26 07:40:44.948475: [debug] Loading project config file stack.yaml
#(Stack\Config.hs:960:13)
2017-05-26 07:40:44.954477: [debug] Trying to decode C:\sr\build-plan-cache\i386-windows\lts-6.27.cache
#(Data\Store\VersionTagged.hs:68:5)
2017-05-26 07:40:44.964480: [debug] Success decoding C:\sr\build-plan-cache\i386-windows\lts-6.27.cache
#(Data\Store\VersionTagged.hs:72:13)
2017-05-26 07:40:44.975485: [debug] Using standard GHC build
#(Stack\Setup.hs:600:9)
HttpExceptionRequest Request {
host = "raw.githubusercontent.com"
port = 443
secure = True
requestHeaders = []
path = "/fpco/stackage-content/master/stack/stack-setup-2.yaml"
queryString = ""
method = "GET"
proxy = Nothing
rawBody = False
redirectCount = 10
responseTimeout = ResponseTimeoutDefault
requestVersion = HTTP/1.1
}
(InternalException (HandshakeFailed (Error_Protocol ("certificate rejected: [InvalidSignature SignatureInvalid]",True,CertificateUnknown))))
I'm running Windows 10 and get the same error in GitBash, Cygwin and DOS Command Line, both as User and as Administrator.
I have tried fetching the file into IE (https://raw.githubusercontent.com/fpco/stackage-content/master/stack/stack-setup-2.yaml) as suggested for similar issues regarding the retrieval of files from GitHub. I can get the file but stack still fails afterwards.
Following comments I also tried curl from GitBash and get
* About to connect() to raw.githubusercontent.com port 443 (#0)
* Trying 151.101.48.133...
* Connected to raw.githubusercontent.com (151.101.48.133) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Users\pauldenby\AppData\Local\Atlassian\SourceTree\git_local\bin\curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
I am currently trying to import the missing certs into curl-ca-bundle.crt but I'm not sure that'll help with the fundamental problem. Is it documented anywhere where stack will look for trusted CAs?
I can also run curl --insecure. As a very temporary workaround, is there anything similar for stack?
I have created a basic script which checks for an email in my inbox, and yesterday everything was working fine. But today all i get is a HTTP404 when I run the same code.
I suspect that outlook.office365.com might be throttling my requests since I ran this 1 time every minute for about 36 hours. But how can i tell if that is the case?
Here are my curl command:
curl https://outlook.office365.com/api/1.0/Me/folders/Inbox/messages -u login#email.outlook:password --insecure --show-error -H Content-Type:application/json -v
and the output:
* About to connect() to outlook.office365.com port 443 (#0)
* Trying 132.245.48.18... connected
* Connected to outlook.office365.com (132.245.48.18) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: C=US; ST=WA; L=Redmond; O=Microsoft Corporation; OU=Microsoft Corporation; CN=outlook.com
* start date: 2015-02-13 00:38:15 GMT
* expire date: 2016-02-13 00:38:15 GMT
* subjectAltName: outlook.office365.com matched
* issuer: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation; OU=Microsoft IT; CN=Microsoft IT SSL SHA1
* SSL certificate verify ok.
* Server auth using Basic with user 'login#email.outlook'
> GET /api/1.0/Me/folders/Inbox/messages HTTP/1.1
> Authorization: Basic Ybase64stringU=
> User-Agent: curl/7.21.3 (x86_64-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: outlook.office365.com
> Accept: */*
> Content-Type:application/json
>
< HTTP/1.1 404 Not Found
< Content-Length: 0
< Server: Microsoft-IIS/8.0
< request-id: d7967869-c282-4a28-9da2-6b80edd7d965
< Set-Cookie: ClientId=XXQW0EIP0KK9NUIRICS8BQ; expires=Fri, 28-Oct-2016 13:04:08 GMT; path=/; secure; HttpOnly
< X-CalculatedBETarget: AM2PR09MB0452.eurprd09.prod.outlook.com
< X-BackEndHttpStatus: 404
< X-DiagInfo: AM2PR09MB0452
< X-BEServer: AM2PR09MB0452
< X-Powered-By: ASP.NET
< X-FEServer: HE1PR01CA0033
< Date: Thu, 29 Oct 2015 13:04:08 GMT
<
* Connection #0 to host outlook.office365.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
any ideas?
If you had exceeded a quota, I would expect you would receive a 429 status code. Microsoft don't usually publish an exact threshold for their services as they reserve the right to adjust them...
so users can consume the maximum number of resources without degrading the reliability and performance
(The above quote is specifically in respect of Sharepoint, but given the lack of published limits for pretty much all REST APIs I imagine the principle holds).
The 404 would usually indicate something isn't quite right... if your user account was reasonably new it could indicate it hadn't propagated to all servers yet (although in your case that doesn't seem to be the issue as you must have had the account for >24 hours).
From a URL point of view... the v1 URL is outlook.office.com/api/v1.0/me/messages and the new beat URL is outlook.office.com/api/v1.0/me/messages these addresses seem to work for me... but I get a 404 if I use the address you are using... so double-check the URL.
I'm running CouchDB 1.6.1 on Windows 64bit server 2012 R2, usually we use nginx to manage the SSL however this time I've attempted using CouchDB directly.
Our SSL is a GlobalSign organizational SSL and I have the cert, private key and intermediate cert from the provider. I have setup my local.ini as follow:
[daemons]
; enable SSL support by uncommenting the following line and supply the PEM's below.
; the default ssl port CouchDB listens on is 6984
httpsd = {couch_httpd, start_link, [https]}
[ssl]
cert_file = ../ssl/organizational.crt
key_file = ../ssl/privatekeyfile.key
; set to true to validate peer certificates
;verify_ssl_certificates = false
; Path to file containing PEM encoded CA certificates (trusted
; certificates used for verifying a peer certificate). May be omitted if
; you do not want to verify the peer.
cacert_file = ../ssl/intermediate.crt
When I check via curl I get the following output:
curl -k -v https://companyURL.com:6984
* Rebuilt URL to: https://companyURL.com:6984/
* Hostname was NOT found in DNS cache
* Trying IP.IP.IP.IP...
* Connected to companyURL.com (IP.IP.IP.IP) port 6984 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* Server certificate:
* subject: C=GB; ST=LONDON; L=LONDON; OU=IT; O=COMPANY;CN=*.edge10hosted.org
* start date: 2015-03-27 14:18:04 GMT
* expire date: 2018-05-03 11:17:17 GMT
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Organization Validation CA - SHA256 - G2
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> User-Agent: curl/7.39.0
> Host: companyURL.com:6984
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: CouchDB/1.6.1 (Erlang OTP/R16B02)
< Date: Tue, 31 Mar 2015 13:00:39 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 151
< Cache-Control: must-revalidate
<
{"couchdb":"Welcome","uuid":"34155abcacbffc53e67a224f5f1ea7c7","version":"1.6.1","vendor":{"version":"1.6.1","name":"The Apache Software Foundation"}}
* Connection #0 to host companyURL.com left intact
And running https://www.sslshopper.com/ssl-checker.html checks out fine.
CouchDB logs show
SSL: certify: tls_connection.erl:2286:Fatal error: decode error
Any thoughts as to what the issue could be as the certificates work fine elsewhere and via nginx.
I am failing a server security scan on Windows 2008 R2, with
TLS Protocol Session Renegotiation Security Vulnerability TLS SSL Man In The Middle CVE-2009-3555
The scan results recommend an upgrade to openssl 0.9.8l or higher.
I am using the latest version of tcnative-1.dll (1.1.29 13/02/14) which, as I understand it is built using the native libraries and openssl libraries.
Is the only way I can resolve this is to build tcnative myself with the latest version of openssl?
Looking at the http://tomcat.apache.org/native-doc/ build section I need MS Visual Studio (which I don't have and have never used).
Has anybody else build it? If so I cannot find it.
This result is a false positive. I've performed various tests with various versions of Tomcat using the 1.1.29 APR/native connector and in none of those test did insecure renegotiation occur.
Note that Tomcat - depending on version, connector and configuration may support secure renegotiation.
The most definitive test was with OpenSSL 0.9.8.k (i.e. a version of OpenSSL that is vulnerable to CVE2009-3555 and will attempt an insecure renegotiation). When I try this, the connection blocks and eventually times out.
You need to find a better security scanner.
For completeness, the output of the test was:
$ ./openssl s_client -connect 192.168.23.9:8443
CONNECTED(00000003)
depth=1 /C=US/CN=ca-test.tomcat.apache.org
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=US/CN=localhost
i:/C=US/CN=ca-test.tomcat.apache.org
1 s:/C=US/CN=ca-test.tomcat.apache.org
i:/C=US/CN=ca-test.tomcat.apache.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDSTCCAjGgAwIBAgICEAMwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCVVMx
IjAgBgNVBAMTGWNhLXRlc3QudG9tY2F0LmFwYWNoZS5vcmcwHhcNMTMwMjI4MDUy
ODQyWhcNMTUwMjI4MDUyODQyWjAhMQswCQYDVQQGEwJVUzESMBAGA1UEAxMJbG9j
YWxob3N0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5295PxiHkd0n
mDQkeVhH+cJpK9hbwOC7SlfWALW7arBmhFy48BIKJycynIIqLw9pd6bpDd9kMVHA
QR7c1HRRnKO4URNYc+4hnPljghvCLEnDCXD/qfOvogwLYC9q26UBRT40kI5naetF
8zQphds5ipnCD3IVIf1UNaZ7pzDLHk09MiTGS4RPX2D/ZF5oytj63ph9QARgt65Q
7MiMrt2UgUEYWwNjDysCYwqVau1+aOa21VbpTmDqHZVYM76iElXLf5zElwvbwJQJ
KrOf4Wt4DWMaQdVr29hIWQSI0RHV50UoDnwbeHUgff9/4dbq5MVRd0FCMEv/KTM9
iViUaVtwJwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVu
U1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUMNurcJQ0yv11RqvO
4kqpnnS8abswHwYDVR0jBBgwFoAUsDu8yfooXz4EH5tsx4to2AGw+D0wDQYJKoZI
hvcNAQEFBQADggEBAKvT5ys1022fhypkWPFhy1aohCJ5rA1oH1UN3RYWcsSpdSoO
+LFzaMnuQ9hc+gddP0H7FBe+ZCHYHiVnkrLFu0MdlrbTvRzhpMfu4zcLkhRWyq2o
dluAyUKMifFCboz7odeY1W1Jmf629sbzzI8GVG4C9Y9L8YasFJNsdCUmRHpbgjxX
1uUUbrcpU+RAei8QXf8of+XlVGw4+rknlyppYLpKWihlsYHgt6F01uYHgW24WcNF
vXyoF2cf/FIabJCHTaGYUYwpaoTZDSSohmpearf5J5tSN5a1/ZQRysTZbWmB+pY0
Yzp8SS0GSK6xFFkSKY5ZPQOZQpDmgt8Iz9d37AA=
-----END CERTIFICATE-----
subject=/C=US/CN=localhost
issuer=/C=US/CN=ca-test.tomcat.apache.org
---
No client certificate CA names sent
---
SSL handshake has read 2433 bytes and written 322 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: E98ED9D885D761C7B23AF93DC15C53D0680AF2D8345A37699549E48C9D4E18AE
Session-ID-ctx:
Master-Key: FA2C87FB24C68186D1CC63FEEF459B7DE4BA0F304D60F2293AB3C1C23DF03566F51DDB61A9576A1FE9C021CB3438B4C7
Key-Arg : None
Start Time: 1395309769
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
GET / HTTP/1.0
R
RENEGOTIATING
7087:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: