SSLError when moving app to Apache mod_wsgi - apache

So with the help of Graham I realize I need to rebuild the mod_ssl.so to point to the new OpenSSL version.
I found the following post with similar problem but not much suggested: https://stackoverflow.com/questions/36756641/rebuild-mod-ssl-so-on-apache2-on-macosx
Is it possible to only rebuild the mod_ssl.so only or do I need to rebuild Apache?
Any specific flags to use?
Is homebrew the way o go and how do I avoid having two installations of Apache?
I am on 10.11.6 and using MacOS Server 5.2 (If that has an impact)
I have integrated the following framework under a flask app and made it work. https://github.com/playingmedia/swish-python
So basically it makes a Request with pyopenssl with included certificates.
This is working fine in my flask app, but when I move it to my Apache Server (configured to be accessed through TLS - not sure if that is relevant) it gives me the following error: SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:590)
I am wondering if there is mod_wsgi setting I need to manipulate of there could be any permission issues...
I included another framework using Suds with TLS without on the Apache server any problem so wondering if there is any known issues with Request library and pyopenssl under mod_wsgi?
Have tried to google quite a lot but perhaps I am not typing in the right key words
Thx

Related

Upgraded OpenSSL - How do I get Apache HTTPD to Use?

I recently had a need to upgrade an old server. The server fulfills a very specific purpose and as such has not been kept up to date. With the recent push for SSL to utilize SHA256 I needed to upgrade a few packages.
Short Background
The server is RHEL3 (yes, that is correct).
I downloaded and built OpenSSL 0.9.8q and ensured it was the only instance of OpenSSL on the server (moving the old instance to a backup directory). I then downloaded and built cURL 7.15.5 with the ./configure --with-ssl=/usr/local/ssl - pointing the with-ssl to my new OpenSSL directory.
Once cURL was built I tested my connection to the resource that is requiring sha256 using cURL. My connection test was successful using cURL.
On to my problem and question
I downloaded httpd 2.0.59 and built it with --enable-ssl and --enable-so, but my tests did not work.
I also tried to d/l & build httpd 2.0.63 but I was having trouble getting 2.0.63 working at all. I then took the mod_ssl built from 2.0.63 and put it into the 2.0.59 directory...no luck either.
I feel I am missing some element that connects httpd to my newly installed OpenSSL. What do I need to do to ensure mod_ssl is using my new version of OpenSSL on the server?
I understand I am quite a few releases behind with my httpd instances, but again, this is an old server with a specific purpose. My only goal is to get it working with sha256, not buy a new server with the latest RHEL, etc.
Thank for any input/assistance.
Running
./configure --help |grep ssl
gives
--with-ssl=DIR SSL/TLS toolkit (OpenSSL)
So just like the curl build you could try adding that.
Assuming you are not going to do the sensible thing and upgrade the OS.

Yosemite SSL: CA certificate set, but certificate verification is disabled

Since installation of Yosemite I keep getting error SSL: CA certificate set, but certificate verification is disabled. It occurs with every https url in Terminal.
Can't find how to fix this, any suggestions ?
thanks
Frank
For others coming here trying to figure out why they are running into this issue with Wordpress and maybe also WooCommerce and are on OS X Yosemite then you will want to follow Asaph/Cupcake's answer to "osx 10.10 Curl POST to HTTPS url gives SSLRead() error" (https://stackoverflow.com/a/26538127)
Basically the issue is cURL is using Apple's SecureTransport instead of OpenSSL. The linked to answer will walk you through testing the SSL Version and then fixing it.
One caveat I ran into is I had already installed php 5.5.21 via homebrew but my system was not using it. I unlinked 5.5.21 by doing "brew unlink php55
I found a wrong setting in my .gitconfig, in the [http] section. I added sslVerify=falseand deleted the other settings in this section, and it fixed my problem.

Python BaseHTTPServer vs Apache and mod_wsgi

I am setting up a very simple HTTP server for the first time, am considering my options, and would appreciate any feedback on the best way to proceed. My goal is pretty simple: I'm not serving any files, I only need to respond to a very specific HTTP POST request that will contain geolocation data, run some Python code, and return the results as JSON. I do need to be able to respond to multiple simultaneous requests. I would like to use HTTPS.
In looking on stackoverflow it seems I can potentially go with BaseHTTPServer and ThreadingMixIn, or Apache and mod_wsgi. I already have Apache installed, but have never configured it. Are there compelling reasons to go the more complicated Apache route (more complicated to me, because I will need to do research on configuring Apache and getting mod_wsgi going but already have a test instance of BaseHTTPServer up and running), or is it equally safe, secure (very important), and performance-oriented to use BaseHTTPServer for something so simple?
BaseHTTPServer is not a production grade server.
If you don't understand how to set up Apache, but want to get something with mod_wsgi running quickly and easily, then you probably want to look at mod_wsgi express.
This gives you a way of installing mod_wsgi using Python 'pip' and also provides you a way of starting up Apache/mod_wsgi with a auto generated Apache and mod_wsgiconfiguration such that you don't even need to know how to configure Apache.
The next version of mod_wsgi express to be released (version 4.3.0, likely released this week), can even set up a HTTPS site for you, with you just needing to have obtained a valid certificate or generated a self signed certificate.
I would suggest if interested you use the mod_wsgi mailing list to ask for more details about using mod_wsgi express for running a HTTPS site.
http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6#Asking_Your_Questions
You can start playing around though with it for a normal HTTP site by following instructions at:
https://pypi.python.org/pypi/mod_wsgi

OpenSSL error when authenticating user for DocusignAPI

We are trying to use composite templates (fillable PDFs) and embedded signing using the REST API. We are using the docusign_rest gem in conjuction with our custom code to create composite templates and embedded signing. The docusign_rest gem is used for authentication and is giving the following error:
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed)
On the local dev machine, we simply provided path to a certificate file at the time of starting the dev server, but on a remote machine this is not feasible.
Is it possible to skip the SSL check for a demo purpose? This SO link seems to suggest that it is possible. If yes, then how can we achieve that?
If not, then is there a quick way to fix it or do we have to install SSL certificates and configure the server to read those?
We are using ruby 1.9.3 , rails 3.2.11 and Apache2 (so that would mean enabling the SSL module).
I believe for demo (demo.docusign.net) you can use https OR http. What happens if you simply use http? Does that resolve your SSL error?
In either case, you'll eventually need to resolve this though because for production (www.docusign.net) you need to use https. The problem is most likely in your Ruby code or with your certificate. For testing purposes I'd try making a cURL request through the command line to see if that works.
See here for some examples of making DocuSign REST API calls using cURL

Pushing my Mercurial Repository through HTTP with Apache and Windows

So I have managed it. I can clone mercurial-repositories remotely using HTTP to my Windows Server 2003 machine and the ipaddress from that machine. Although I did deactivate IIS6 and am using Apache 2.2.x now. But not all works right now...darn! Here's the thing:
Cloning goes smooth! But when I want to push my changes to the original repository I get the message "cannot lock static http-repository". On the internet I get to read several explanations that Mercurial wasn't designed to push over HTTP connections. Still, on the Mercurial website there's something about configuring an hgrc file.
There's also the possibilty to configure Apache to host via HTTPS (or SSL). For this you have to load the module enabling OpenSSL and generating keys.
Configuring the hgrc file
Just add "push_ssl = false" under the [web] line. But where to put this file when pushing your changes back?! Because I placed it in the root of the server, in the ".hg" directory, nothing works.
Using SSL/HTTPS with Apache
When I try to access 'https://myipaddress' it fails, displaying a dutch message which would mean something like "server taking too long to respond". Trying to push also gives me a dutch error message which means about the same. It can not connect to my server via https although I followed the steps exactly at this blog.
I don't care which of the above solutions will work for me. Turns out none of them work so far. So please, can anyone help me with one of the solutions above? Pick the easiest! Help will be greatly appreciated, not only from me.
Summary
-Windows Server 2003
-Apache 2.2 with OpenSSL
-Mercurial 1.8.2
-I can clone, but not push!
Thank you!
Maarten Baar(s)
It seems like you might have apache configured incorrectly for getting it to do what you want. Based on your question it sounds like you have a path (maybe the root of the server) pointing to the repository you want to serve.
Mercurial comes with a script for this exact purpose, in the latest version it is hgweb.cgi. There are reasonably good instructions for setting it up on the mercurial site. It should allow both cloning and pushing. You will need the push_ssl=false if you will not be configuring https and also an allow_push line which will let certain users, or all (*) push to the repository. But all that should be part of the setup docs.