My Apache server works fine without -DSSL, but does not start with SSL. This happened after I re-install the certificate because of expiration. (it used to work before) I would love to have some tool to check up if my newer setup of ssl key and certificate is correct or not. That would include permission, ownership etc..
Or is there any way to figure out why it doesn't work with SSL?
You can check your configuration files for syntax errors without starting the server by using apachectl configtest or the -t command line option.
That said, I don't think that Apache fails silently. There must be something in Apache's logs. Can you check this and provide the trace?
PS: You should add details on your environment such as your OS (Windows, GNU/Linux, Unix, etc), the Apache version, etc. This could help.
I would suggest, https://globalsign.ssllabs.com/ if your website is publically available.
Related
We are running a legacy application on an Apache v7.0.47 server behind an Apache2 HTTPD proxy (v2.4.23).
I am trying to upgrade the Java version on the server (used by both the proxy as well as the tomcat) from v1.8.0_181 to v1.8.0_303.
After that upgrade the Tomcat does not respond any more to the Apache's passed-on requests (the application itself comes up and runs fine).
Both the Apache on its network facing side as well as Apache and Tomcat among each other were configured to "talk" TLS1.2 already for a while, so I don't think that the disabling of TLSv1.0 and TLSv1.1 in the later Java version is the cause of the issue here. And there is no error message in the logs giving any clue. The only indication is, that the Tomcat seems to close and tear down the connection without any response after having receiving the request. That seems to happen already in the SSL layer, since there is no entry in the access-log (of Tomcat).
Switching back to the "old" Java gets things going again, so firewall, network etc. are definitely NOT the issue here. With the newer Java version the connection setup fais again, causing the HTTPD to emit a "502 Bad gateway" error.
Any idea anyone what could cause the Tomcat to reject the HTTPD's requests just based on the Java version? Additional SSL verifications enabled by default in the newer stack? I searched extensively but didn't surface any suspect, yet.
Later addition: trying to identify the issue I found out that with Java v1.8.0_231 things are still working, with v1.8.0_241 and higher it fails.
Inspecting the release notes now to find a hint...
Any ideas or experiences with that upgrade anyone?
Just for the records - in case someone else stumbles over this question:
The issue here was that from Java v1.8.0_241 on upwards Java security verifies that a certificate chain read from a certificate store is rooted in a CA certificate that has a proper CA-flag. Since we were using an old certificate and trust store that had been generated with an old release of the java keytool back than this flag was missing and the new Java version thus rejected all the entries in that certificate file. It thus aborted the SSL connection setup and simply closed the connection without any response or indication.
There is a VM option -Djdk.security.allowNonCaAnchor=true that one can add to Tomcat's JAVA_OPTS variable (typically in a file setenv.sh) to disable this verification. After adding that our Tomcat was again responding to SSL-requests and worked OK again.
BTW: when trying to analyze SSL issues like the above the option -Djavax.net.debug=all:handshake:verbose proved to be a real live-saver! With this option one gets very details log output and can follow SSL handshakes and connection setups in detail. Once I had finally gotten a first useful error message pointing to this CA-flag issue searching for a solution (or rather workaround in this case) proved to be a snap compared to the initial search for what could be the issue here.
If so, how?
And how to check wether they are running?
Is there something like the manager for tomcat?
I have an Apache Server running, that has been installed automatically by a package installation routine. I expect that the routine installed OpenProject on the server. But I cannot point to the application.
So I don't know wether OpenProject is not installed, not started or pointing to it with
http://185.82.22.144:80/OpenProject
is wrong.
The installation routine seemed to work fine, with no error messages.
peter
No, because the way you are using language implies that you are asking about functionality which is exposed by the Apache server - but that functionality is not "in" the webserver, apache merely provides a means for accessing it.
I want to write a small back-end REST server using Play! Framework 2.1.3. This server will only serve WS requests, and all communication to it must be made over SSL. For this reason, I don't want to have an HTTP port open for this server at all.
I've seen this question regarding SSL on various Play! branches, and according to the linked discussion, the only way to open SSL port (which worked for me) is to add JAVA_OPTS before running the server, like so:
JAVA_OPTS=-Dhttps.port=9443 play run
This setting opens both HTTP and HTTPS ports for communication.
My questions are:
Is it possible to open the server only for SSL communication? How?
Is there a configuration file where I put this setting?
Thanks!
This is super easy with Play 2.2, not sure it works on 2.1.3, I didn't see it in the 2.1.x docs...but was in the 2.2.x docs...so give it a shot, it might be implemented.
Throw this in your configuration file :
http.port=disabled
Or you could run it with the command line option :
-Dhttp.port=disabled
http://www.playframework.com/documentation/2.2.x/ConfiguringHttps
I'm using a Debian VPS on DreamHost and wanted to install a feature-rich customer issue-tracking system (not for software development like Bugzilla). OTRS made my shortlist and I followed the Installation Instructions through the "Web Server Configuration" step (/etc/init.d/apache2 restart), but the restart step reported failure. Nevertheless pgrep apache showed it was running. In fact, it turned out that although www.mysite/otrs/installer.pl was running, my regular website showed a page claiming it had no content (but when I looked in the website's folder, its content was fine, just not being served).
DreamHost Support was very helpful, but explained that they don't use the standard Debian Apache server for hosting websites and instead use their own. Specifically, the Debian server is in /etc/apache2, but the DreamHost server is in /dh/apache2. DreamHost Support determined that the OTRS installation instructions were configuring the usual Debian Apache location which somehow prioritized that server instead of the DreamHost server. They tried moving the otrs.conf file into /dh/apache2, but though the regular website was working again, the OTRS page wasn't.
Has anybody had success installing OTRS on a DreamHost VPS?
I've consulted one of our admins on this, and these are our suggestions:
You will either need to:
Adapt DreamHost's Apache build to incorporate the OTRS modifications
Get Debian Apache up and running
Both options will require an admin user and some knowledge of Linux command line and Apache management tools. You will also need to set your VPS to UNMANAGED, which means that any changes in the DH Web Panel to any of your domains will have no effect whatsoever. Just make sure the DNS records for any domains are pointing to your server. You will also need to be able to manage your own Apache configurations.
NOTE: This will also essentially mean that DreamHost support cannot and will not troubleshoot your domains. Unmanaged means unsupported in any way!
There are a few core differences between DreamHost's apache2 configuration and the default Debian build. The first issue I observe is that DreamHost's configuration does not allow for extra configuration files to be loaded in the manner that the OTRS documentation suggests. This means if choosing option 1, you will need to manually insert the OTRS directives into DreamHost's configuration files, which may prove difficult.
I would recommend moving or otherwise disabling the /dh folder entirely after setting your VPS to unmanaged. This will not allow DH-default Apache to start when the VPS starts. You may also need to remove the DH Apache startup script in /etc/rc3.d/S02httpd2 and the actual script at /etc/init.d/httpd2.
Once you have your own version of Apache running successfully, you might consider copying the VirtualHosts that were previously at /dh/apache2/apache2-ps/etc/httpd.conf into your own domain configuration files in your conf.d directory, or you can shuffle your website files around and configure your Apache to your desire.
Once you've got your own flavor of Apache running, you should be able to implement the OTRS instructions per their wiki. :)
I use mod_spdy to realize SPDY on apache. But I met some problems.
I did every step on ubuntu according to Google's document of installing mod_spdy.And I realized https on Apache. When I checked if mod_spdy has worked, I sent https request to the server, but I donot see server's domain listed in the "SPDY session" table that means the mod_spdy don't work. I also checked Apache server logs, and I didn't find any error message from mod_spdy.
I hope somebody can help me to deal with this problem.