On 25/03/2015, at 3:53 AM, Kyle Handy <[email protected]> wrote:
> Graham, > > I've been using all of the command arguments you've suggested, with a couple > additional ones > > mod_wsgi-express start-server --host 0.0.0.0 --port 8000 --https-port 8001 > --ssl-certificate /path/to/cert/and/key --server-name FQDN --startup-log > --access-log --log-to-terminal I don't think it will make an difference, but can you try without '--host 0.0.0.0'. The configuration should allow external clients to connect by default. The '--host' option should only be used if want to limit to listening on a specific device interface. For --server-name, does the server name used in URL match that exactly? > When running I can access the server, again on the local network only, and > their are no SSL warnings: the connection is secure. Thanks to the > --access-log option I can see the request come in and the status code of the > response checks out as it should be. > > There is only one warning that catches my eye in the startup log: > [Mon Mar 23 21:37:47.275863 2015] [ssl:warn] [pid 24357:tid 139801017251648] > AH01909: 0.0.0.0:8001:0 server certificate does NOT include an ID which > matches the server name > You may see this warning because the generated configuration creates a dummy VirtualHost entry with no ServerName to act as catch all so that arbitrary name based virtual host access isn't handled. In other words, configuration will only accept requests against site set by --server-name or --server-alias and all others should see Forbidden returned. At least for HTTP would get Forbidden. For HTTPS I will need to check again what happens if Host header doesn't match specified server name. I have seen cases where when I have stuffed things up for HTTPS that it just didn't connect or hung, which sounds sort of similar. I will do some more checking on this. > I've followed this warning message to this serverfault post which instructs > to check the CN of the cert to make sure it matches the server-name; it does. > > I do not see this as a probable cause for our issue connecting from outside > the local network. > > More on the certificate.... > > Our cert was signed via InCommon CA, and the response from InCommon contained > multiple links to different cert files. > > PKCS#7 Base64 encoded > PKCS#7 Bin encoded > X509 Base64 encoded > X509 Certificate only, Base64 encoded > X509 Intermediates/root only, Base64 encoded > X509 Intermediates/root only Reverse, Base64 encoded > Through multiple trial/error we found that the only successful certificate > file for mod_wsgi-express is the X509 Certificate only, Base64 encoded. > Maybe the omitted component in choosing the certificate only could have led > us to this issue? So what you need are two files, the SSL certificate file, often using a .crt extension. And the SSL certificate key file, often using a .key extension. Rather than use --ssl-certifcate to try and refer to both at same time, you can use separate options to be explicit if using recent mod_wsgi-express version. --ssl-certificate-file some/path/server.crt --ssl-certificate-key-file some/path/server.key If what you were given was a .pem file it from memory has both the certificate and key in the one file. I have generally found I have had to extract the .crt and .key files separately from that to get it to work. I always have to Google for the steps to do that. Anyway, let me do that checking I mentioned. If you can at least confirm that the server name in URL used matches --server-name, and that the request isn't passing through any intermediary proxies, although since you are using HTTPS that is probably unlikely. Graham > > Thanks for replying so quickly, > > Kyle > > > On Saturday, March 21, 2015 at 1:54:24 AM UTC-7, Graham Dumpleton wrote: > > On 21/03/2015, at 10:13 AM, Kyle Handy <[email protected]> wrote: > > > Hello, > > > > I've been developing a Django REST API that supports an iPhone > > application's data needs and user tracking. We have been using mod_wsgi > > express to host the API. When working over HTTP the API works great, but we > > have recently configured the HTTPS portion of the server and it we cannot > > reach the server over 3G/4G internet connections. > > > > The server responds to the following HTTPS requests: > > > > PC browser request on Wi-Fi > > PC browser request on landline. > > iPhone device request over Wi-Fi > > > > The server DOES NOT even RECEIVE the following HTTPS requests: > > > > iPhone device request over 3G > > iPhone device request over 4G > > > > Is there any special configuration or extra accommodation that is required > > by Django or the mod_wsgi module in order to support requests over 3G/4G > > via HTTPS? > > > > Any help is appreciated. > > What is the command line arguments you are giving to mod_wsgi-express? > > It would need to be something like: > > mod_wsgi-express start-server --https-port 8443 --server-name > ssl.example.com --ssl-certificate-file server.crt --ssl-certificate-key-file > server.key > > You could also use the all in one combined '--ssl-certificate' option, or > would have to if on older mod_wsgi-express version. That variant of the > option would be specified as '--ssl-certificate server'. That is, the common > base name of the SSL certificate and key file. > > Very important is that you must use the '--server-name' option and it should > match the host name allowed by the SSL certificate and must match the host > name appearing in the URL used to access the site. > > Also suggest adding the option '--access-log'. This will turn on request > access logging and should show whether requests even reach the server, even > if rejected. If they don't even reach the server, then would take it as being > an external routing issue. > > To validate there are no complaints from Apache on startup about the SSL > certificate, check the error log. To be sure you can also add '--startup-log' > and check the startup log for any extra error messages in case not being > logged to the error log. > > Graham > > > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
