I am running a server that accepts https requests. I have generated my own certificate. When going to the site in firefox I get the unknown certificate error, but that's fine. This (I think) indicates that port forwarding and such works.
I am trying to use svn with this. When using svn on the server (but using the external ip) it works. Again I get the certificate is unknown, but I don't care.
When using svn on mac OS X I get
SSL negotiation failed: SSL error code -1/1/336032856
I've found several posts on google about this, but they all say it's a bug with openssl version 0.9.8, and that using something higher should fix it.
I am currently using openssl 1.0.0c. I have no idea what's going wrong. I also checked the error log in httpd and nothing comes up.
Any ideas on this would really help.
Thanks
Upgrading from SVN 1.6.15 to 1.6.16 fix this issue for me.
I received the same error message when my Apache configuration was wrong - my ServerName parameter in httpd.conf did not match hostname in the self-signed certificate.
I started getting this error from older subversion clients (Tortoise 1.6.4 i think, and pysvn r1280) when our svn server had its Apache instance upgraded. It went from using OpenSSL 0.9.8n to 1.0.0d.
Tortoise got fixed by upgrading to 1.6.16 (uses OpenSSL 1.0.0d).
Fixing pysvn was a different story. The latest version (r1360) came bac kwith the same error. There didn't seem to be much info around apart from hints that OpenSLL might need upgrading. I tried copying in different versions of OpenSSL (libeay32.dll and ssleay32.dll) and here are the results:
0.9.8j (the existing DLL version, bundled with pysvn r1280) FAIL
0.9.8o (bundled with the latest pysvn, r1360) FAIL
0.9.8r (the latest in the 0.9.8 series) FAIL
1.0.0* (the 1.0 series is not binary compatible with pysvn) FAIL
0.9.8L (nabbed from CollabNet SVN 1.6.9 command line client) SUCCESS!
So whatever they fixed in release L got broken again soon after, or there's something special about CollabNet's OpenSSL binaries.
In my case it started happening after some certificates changes on the server side. I tried deleting the .subversion/ dir, updating openssl, openssh, svn, and nothing...
It got finally fixed when I replaced the url host name with the ip address of that host.
In existing working copies was enough with:
svn switch --relocate http://hostname.com https://ipaddress
Not sure if this is a bug or what, but it seems that the new certificates are not recognized and keeps using the old cached ones for a given host name.
I agree with the earlier answer by Lukas Cenovsky, that setting ServerName in the apache configuration fixes the problem.
In this link http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf it is said that the error originates from the SSL library.
The full error message(just to enable better google indexing) I receive is:
$ svn ls https://www.OMITTED.dk/svn
svn: E175002: Unable to connect to a repository at URL 'https://www.OMITTED.dk/svn'
svn: E175002: OPTIONS of 'https://www.OMITTED.dk/svn': SSL handshake failed: SSL error code -1/1/336032856 (https://www.OMITTED.dk)
In the file /etc/apache2/sites-available/ssl (debian linux)
I added the ServerName as:
NameVirtualHost *:443
<VirtualHost *:443>
ServerAdmin webmaster#localhost
SSLEngine On
ServerName www.OMITTED.dk
See what happens if you eliminate the SSL problem by adding your generated certificate to your client's trusted certificate store.
One step ahead, my case is a MSWindows Client workstation and a CentOs server with Apache.
Using Tortoise Subversion 1.6.16, I realise that after execute a "svn checkout https://OMITTED.dk/project", I got the same ssl handshake error.
What I did was
update c:\windows\system32\drivers\etc\hosts with "IP_address
OMITTED.dk"
update the entries with the project directory. Edit the
file project/entries and replace the IP_address by OMITTED.dk.
Thus I try the command : svn update path_to_project --non-interactive --trust-server-cert.
Hope will be usefull
Related
Anyone please let me know if sslprotocol TLS1.3 can be enabled in apache 2.2 or 2.4.
There is a backport available for the 2.4 branch: [https://pastebin.com/raw/7hs9WgSH]
Apply this patch to the current (2.4.33) sources and then compile it together with openssl1.1.1-pre headers. Tested and working with Debian sources, openssl1.1.1 is available in unstable.
To get TLSv1.3 finally enabled, you need to change your ssl config to something like this:
SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:...
SSLProtocol TLSv1.3 +TLSv1.2
Client tested with current nss libs togehter with Waterfox.
The unofficial backport should soon be obsolete. Apache httpd team planned to release 2.4.36 with openssl 1.1.1 and tlsv1.3 support.
Due to an issue with h2 this has been stopped, you can read more about it here:
lists.apache.org/
If you still want to compile by yourself, you can
either check out the source via github (tag: 2.4.36)
or download the source directly from apache dist server (content not static, will no longer be present as soon as an update was uploaded)
Maybe you want to apply the h2 fix from rev 1843954
When I use wget command in RHEL 6.5, getting the error
Error parsing proxy URL. Bad port number.
The command used to set the proxy was
export http_proxy="http_proxy://username:password#address:port/".
Yes I know this issue can be resolved by using
http_proxy=address wget --proxy-user=username --proxy-password=<password> url.
But I want to install a package and during installation, it will need to download few other packages. so the proxy should be already set and ready before the installation. How can we resolve this?
The password I used caused this issue as it had a # in it. I replaced # with %23 [UTF encoding] and now this is working fine.
make us Use of "--no-proxy"
Example : wget https://dl-ssl.google.com/linux/linux_signing_key.pub --no-proxy
This will elimimate the current proxy and try to download what ever we need..
I set up the proxy on Ubuntu using general system settings (manual option).
The problem was I pasted the proxy URL with a port, while the port is also separately specified there, in different field.
I am trying to enable DKIM signing in Virtualmin per these instructions.
When I save the changes, it begins adding DKIM records to the various virtual domains, until it hits a specific domain which has lots of alias domains. It stops with this error:
Failed to save DKIM settings : Missing file to open at
virtual_server::/usr/libexec/webmin/virtual-server/feature-dns.pl line
2782
The applicable code in this .pl file is:
else {
# On local BIND
$file = &get_domain_dns_file($ad);
>> line 2782: &open_tempfile(EMPTY, ">$file", 0, 1);
&close_tempfile(EMPTY);
&create_alias_records($file, $ad,
$ad->{'dns_ip'} || $ad->{'ip'});
$recs = [ get_domain_dns_records($ad) ];
}
Then I tried adding this domain to the box "Never sign domains".
It still hung at the same domain, this time trying to "remove DKIM records".
Virtualmin version 4.04 GPL
Webmin version: 1.660
Linux version: Centos 6.5 64-bit
Running Postfix, Dovecot, Bind, Apache HTTP 2.x etc.
Multiple virtual domains in Virtualmin
Thanks for any help.
Version 4.04 of Virtualmin was released well over a year ago. Upgrade to the latest version, which is 4.15-2. As far as I know DKIM works readily on CentOS 6 with the current version.
You will also need to upgrade Webmin, as that is also many revisions behind the current version.
If you installed Virtualmin using the install.sh script, you should be able to simply perform an apt-get upgrade to get the latest packages from our repositories. If you haven't updated your system in over a year, you surely have numerous and probably quite serious security vulnerabilities (Webmin/Virtualmin even had a few local file access vulnerabilities last year that were fixed around about version 1.720/4.13).
If the problem persists with a current version of Virtualmin, let me know, and I'll help you sort it out.
I'm new to puppet, but picking it up quickly. Today, I'm running into an issue when trying to run the following:
$ puppet agent --no-daemonize --verbose --onetime
**err: Could not request certificate: getaddrinfo: Name or service not known
Exiting; failed to retrieve certificate and waitforcert is disabled**
It would appear the agent doesn't know what server to connect to. I could just specify --server on the command line, but that will be of no use to me when this runs as a daemon in production, so instead, I specify the server name in /etc/puppet/puppet.conf like so:
[main]
server = puppet.<my domain>
I do have a DNS entry for puppet.<my domain> and if I dig puppet.<my domain>, I see that the name resolves correctly.
All puppet documentation I have read states that the agent tries to connect to a puppet master at puppet by default and your options are host file trickery or do the right thing, create a CNAME in DNS, and edit the puppet.conf accordingly, which I have done.
So what am I missing? Any help is greatly appreciated!
D'oh! Need to sudo to do this! Then everything works.
I had to use the --server flag:
sudo puppet agent --server=puppet.example.org
I actually had the same error but I was using the two learning puppet vm and trying run the 'puppet agent --test' command.
I solved the problem by opening the file /etc/hosts on both the master and the agent vm and the line
***.***.***.*** learn.localdomain learn puppet.localdomain puppet
The ip address (the asterisks) was originally some random number. I had to change this number on both vm so that it was the ip address of the master node.
So I guess for experienced users my advice is to check the /etc/hosts file to make sure that the ip addresses in here for the master and agent not only match but are the same as the ip address of the master.
for other noobs like me my advice is to read the documentation more clearly. This was a step in the 'setting up an agent vm' process the I totally missed xD
In my case I was getting same error but it was due to the cert which should been signed to node on puppetmaster server.
to check pending certs run following:
puppet cert list
"node.domain.com" (SHA256) 8D:E5:8A:2*******"
sign the cert to node:
puppet cert sign node.domain.com
Had the same issue today on puppet 2.6 on CentOS 6.4
All I did to resolve the issue was to check the usual stuff such as hosts and resolv.conf to ensure they were as expected (compared with a working server) and then;
Removed /var/lib/puppet directory rm -rf /var/lib/puppet
Cleared the certificate on the puppet master puppetca --clean
servername
Restarted the network service network restart
Re-ran puppet
Even though the resolv.conf was identical to the working server, puppet updated resolv.conf and immediately re-signed the certificate and replaced all the puppet lib files.
Everything was fine after that.
I try to import my old project to new SVN server (svn + web_dav+apache), but however I get some weird error while importing with tortoiseSVN.
Adding: C:\tmp\carpirate\test
Adding: C:\tmp\carpirate\test\crawlerTestSuite
Adding: C:\tmp\carpirate\test\crawlerTestSuite\TestP2p.java
Adding: C:\tmp\carpirate\test\crawlerTestSuite\TestMessageHandler.java
Adding: C:\tmp\carpirate\test\crawlerTestSuite\TestGui.java
Adding: C:\tmp\carpirate\test\crawlerTestSuite\TestListener.java
Adding: C:\tmp\carpirate\test\crawlerTestSuite\TestServerConnection.java
Adding: C:\tmp\carpirate\test\crawlerTestSuite\TestCollectorMind.java
Error: Could not open the requested SVN filesystem
I checked read/write permissions from repository (tried to set all to 777), but nothing works. Neither commit do the job.
Do you have any clues, what I'm missing?
If you are in a Plesk world..
Solution: Disable custom error docs for your domain. To do so, log in to Plesk, navigate to the domain and uncheck the "Custom error documents" box in hosting settings.
Alternativ solution: Create a repo named error (or error_docs or whatever you find in the logs).
see :
http://pnpq.blogspot.com/2011/11/apache-svn-could-not-open-requested-svn.html?showComment=1324510115093#c5273051064616678938
We solved the problem, but the solution is a little bit messy and disappointing.
We moved repository parent to a path, with full read/write permissions for apache, authentication files were moved to apache configs, after all that it works.
I suspect it was matter to exclude plesk from webdav access.
Is this a problem of repo format (BDS Berkeley DB or FSFS)?
If so, see Subversion FAQ How do I convert my repository from using BDB to FSFS or from FSFS to BDB?