I am having trouble connecting Redmine to a locally hosted subversion repository using SSL.
I suspect it's the self-signed certificate that usually triggers a warning in the SVN client and browser.
When I try to connect to the local repo through SSL in Redmine, I get a red "Revision not available" error. When I try connecting through svn://, the connection times out, and I have to restart the web server.
Connecting without SSL works without problems.
It would be nice to run subversion on SSL to make it safely accessible from the outside as well. I could run the repository through plain HTTP but would like SSL for outside communication. As far as I understand, subversion can't be run both ways at the same time.
Does anybody know what to do in such a situation? Is there a configuration setting to ignore invalid certificates somewhere?
Looking at the source all redmine does is shell out to the svn binary, see: http://www.redmine.org/projects/redmine/repository/entry/trunk/lib/redmine/scm/adapters/subversion_adapter.rb
So if you can somehow workout how to get the binary to accept your SSL certificate then you will be good.
From http://groups.google.com/group/bitten/browse_thread/thread/d18b21a703c68344?pli=1 it seems you need some manual interaction with svn to accept the cert.
So my suggestion: run svn checkout against your repo as the user running redmine and permanently accept the cert
The reason you are getting this message is because the default user under which redmine is running (www-data) calls the “svn” client to communicate with the repositories but the client replies back to it saying that the certificate is untrusted, thus the connection is closed.
Here's a step by step fix:
http://haknick.tumblr.com/post/2380507902/redmine-svn-subversion-certificate-issue-ubuntu
since you control both the client and the server, is having the client accept the server certificate's issuing authority an option?
if it isn't a permanent option, at least you'd know if it was the problem if you did it temporarily.
Related
I have been working with web services connecting to URLs provided by different clients and so far it has all been done using one-way authentication. Now I'm asked to enable 2-way (mutual) authentication for one of the clients. I did a lot of research and reading but still confused about a lot of things.
I could test successfully on my local machine following instructions from various different articles. But the problem is now to deploy it in production.
Here's what I did for testing: I created a test Web service Host and assigned it a self-signed certificate and created a client to test this. After this I created a client certificate using makecert and verified that this is installed via MMC. I then modified my Host app to only allow clients with certificate and tested from client to see the connection refused due to not providing the client certificate. Then I modified the bindings in the client application to include the certificate name and I was able to connect to the Host successfully. So this completes local hosting.
Now the real problem. The tech team is going to create a certificate in "cert store" on the server. And I need to test again to make sure everything works as expected. We have a few different developers who all want to test on their machines on their local code. Can we all use the same certificate somehow? I don't think we would be allowed to import the certificate but what suggestions could I give them so all of us can use the same certificate?
I'm also confused about issues like difference between windows certificate and IIS certificate. What advantages would the IIS certificate provide?
Thanks for help!
Edit: Could one of the differences between installing on IIS be so that the hosted sites be accessed via SSL connection? This would mean we don't really need to install on IIS if it's just a client certificate. Is this correct?
I'm trying to get a CI setup going and have got Mavericks server downloaded and linked with Xcode all on one machine.
Here's the set up:
Two git repos, hosted on OS X server, named CI and CISubmodule.
CISubmodule added as a submodule to CI
Every time I add bot I get a Host key verification failed error on integration. It's clear from the logs that the server is unable to clone CISubmodule due to an authentication error (I've tried SSH, HTTP, HTTPS) but I don't know why it's failing authentication.
I've set up the server so that logged in users can read and write.
I've tried everything mentioned here.
I'm guessing it's because the server is running as teamsserver and the repo is probably under my username, but I can't figure out how to give it permission to clone. Could it be that the SSH key requires a password? If so, how do I set it up so that it doesn't need a password any more?
Any guidance would be greatly appreciated.
Thanks,
Simon
I had the same case and I am not sure what happend exactly, I think the reason was I had more remote repository accesses and ssh keys pointing git-server side pointing to the same repository.
Deleting the remote repository accesses and cleaning up authorized_keys file helped.
I can confirm the CI server works with submodules, but make sure the .gitmodules file and xccheckout file point to the same repos
you may need to use passphrase-LESS keys for os x server to properly connect to 3rd party hosted git repos. it cannot connect with there is a passphrase needed.
ssh-keygen -p
it worked for us
One thing that helped me was to change my submodule URLs to use HTTPS instead of SSH.
When doing this, make sure that Xcode is actually using the new URLs. Even though I made the changes and pushed them, Xcode was caching the SSH URLs and using them. Remove all your SSH URLS from your server, then also remove them from your client under Preferences->Accounts. Then restart the server and restart Xcode, confirming that the new HTTPS URLs are being used when you create your bot.
We had an issue with our automated build machine yesterday. We are using a TFS Build server, and when it tried to automatically download NuGet packages, we got the infamous "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel" error.
There are a lot of threads around the 'net regarding why this happens. That isn't my question. It can be fixed easily enough by changing your NuGet repository from
https://nuget.org/api/v2/
to
http://nuget.org/api/v2/
or
http://packages.nuget.org/v1/FeedService.svc/
What I'd like to know is why the repository is using SSL in the first place? I assume it is there for a reason, but I can't figure out what. There is no login that would require security. I can't think of any information being sent that would need to be secure. I just want to make sure that by using an unsecured connection (which works just fine) we aren't somehow compromising our build machine.
Can anyone explain what is gained from connecting to NuGet using a secured connection?
I can't think of any information being sent that would need to be
secure.
It is not necessarily because the information you exchange with nuget.org contains anything secret and thus needs to be secure. By using using SSL you will be certain that it actually is nuget.org you're talking with. Without SSL, somebody might in theory be feeding you bogus packages, and that might be a security problem.
As for the issue you're experiencing with "Could not establish trust relationship for the SSL/TLS secure channel", we've had a similar problem when we started using a new build server:
If you look at the SSL certificate presented by https://nuget.org/, the certification path is: GeoTrust Global CA > RapidSSL CA > *.nuget.org
GeoTrust Global CA was missing as a trusted CA on our new build server, so the problem was easily solved by adding them to the build servers list of trusted root CAs (using the MMC console with the Certificates snap-in).
Update:
On a later service, I've experienced the same SSL issue, and adding GeoTrust as a trusted CA alone didn't solve the problem. In addition, the server was also missing to root CA for https://go.microsoft.com/, which is Baltimore CyberTrust Root (go to https://microsoft.com, and you'll be able to view and download the certificate). Adding this to the servers list of trusted root CAs solved the issue.
Today i received an email from apple telling they are changing something connected with push notifications, and wanted to ask what to do with the certificate they gave me link to... My server runs debian lenny, and im using php5 to send push notifications to apple apns. Do i have to just like... add it somewhere, or replace the 'old' one ?
Download the entrust_2048_ca.cer file, and install it on the servers that communicate with Apple's notification services. No need to do renew your actual push certificates, also you should not have to change anything in your code.
The important thing is that the servers that actually communicate with Apple's notification services have the certificate installed.
If you are lucky, your push server is already in contact with a Certificate Authority root, and this will solve the issue for you automagically. However, if you should lose that connection, your notifications will be out of order unless you have a "local" version of the certificate.
I am looking for the same solution, a quick hint from another forum says "simply download the .cer file and install it" http://www.iphonedevsdk.com/forum/iphone-sdk-development/66878-apns-question-email-apple.html.
We will try on our linux server and please see if this works for your situation.
I downloaded and copied the https://www.entrust.net/downloads/binary/entrust_2048_ca.cer file into /etc/ssl on my OpenBSD server. I haven't changed any of my server side code which is actually not using the entrust cert in any way. (I use the certs from Apple's provisioning site.)
On Dec 23rd, my notifications are sent and received with or without the entrust cert. I am confused about how exactly I am supposed to use the entrust cer file.
I think this sentence from the email from Apple tells me I am ok:
If you have been successfully
validating the certificate chain in
the APNs sandbox environment, you
already have the root certificate you
need. Simply install the same root
certificate on your production push
provider servers.
i.e.
Notifications were and are sent, hence my server already has what it needs.
UPDATE:
What I wrote above seems to be the case. If you use a fairly recent server you likely don't have to do anything at all. The sandbox environment has been using 2048 bits since March 2010. If it has been working, you are set. Full info here:
http://www.24100.net/2010/12/latest-apple-push-notification-certificate-changes-decrypted/
My PHP5 scripts that connect to the Apple Push Server are hosted on a Fedora system. For me, the migration was transparent. I had nothing to do despite I can't find the Entrust certificate somewhere on my system. Maybe is it available with the PHP5 SSL library.
I'm running mitmdump (from mitmproxy) on my Macbook Pro, and I'm connecting to the proxy through my Windows desktop PC.
However, Chrome (running on the PC) refuses to connect to so many sites because of the invalid certificates which mitmproxy provides.
Chrome throws the error: ERR::NET_CERT_AUTHORITY_INVALID
Here's what mitmdump shows:
But why? What's wrong with mitmproxy's certificates, why can't it just send back google's as if nothing happened?
I'd like to know how I can fix this and make (force) my desktop PC to connect to any website through my Macbook's mitmproxy.
Answering this question for people who may find this important now. To get the proxy working, you have to add the certificate as trusted in your browser.
For windows follow this: https://www.nullalo.com/en/chrome-how-to-install-self-signed-ssl-certificates/2/
For linux follow this: https://dev.to/suntong/using-squid-to-proxy-ssl-sites-nj3
For Mac-os follow this: https://www.andrewconnell.com/blog/updated-creating-and-trusting-self-signed-certs-on-macos-and-chrome/#add-certificate-to-trusted-root-authority
There are some additional details in the above links; tldr; import the certificate in your chrome://settings url and add the certificate as trusted. That shall do.
This will make your browser trust your self-signed certificate(mitm auto generated certificates too.)
The default certificates of mitmproxy is at ~/.mitmproxy/ directory.
Per the Getting Started page of the docs you add the CA by going to http://mitm.it while mitmproxy is running and selecting the operating system that you are using. This should solve your problem and will allow https sites to work with mitmproxy.
This is the expected behavior.
mitmproxy performes a Man-In-The-Middle attack to https connections by providing on-the-fly generated fake certificates to the client while it keeps communicating to the server over fully encrypted connection using the real certificates.
This way the communication between client and proxy can be decrypted. But the client has to actively approve using those fake certificates.
If that wasn't the case then SSL would be broken - which it isn't.
The whole story is very well explained here:
http://docs.mitmproxy.org/en/stable/howmitmproxy.html