I have a biggest problem for me: SSL
I'm trying install a certificate in my system, and my system have 3 containers that are manage with vagrant.
database (docker)
main System (docker)
proxy(docker) - that's a proxy reverse
When I try install in my container proxy, and install all certificates on folders.
I change in the
<Virtualhost>
## SSL directives
SSLEngine on
SSLCertificateFile "/etc/apache2/ssl/www.mydomain.com.br.crt"
SSLCertificateKeyFile "/etc/apache2/ssl/mykey.key"
SSLCACertificateFile "/etc/apache2ssl/sslroot.crt"
SSLCertificateChainFile "/etc/apach2/ssl/Intermediate.crt"
</Virtualhost>
And obviously my certificates in path folders /etc/apache2/ssl/
When I try restart my Apache, my container "proxy" don't running again and their status is as stoped. Thein I call docker log proxy:
***[error] Init: Unable to read server certificate from file /etc/apache2/ssl/www.patobragado.gedvic.com.br.key
[Thu Aug 06 11:01:02 2015] [error] SSL Library Error: 218529960 error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[Thu Aug 06 11:01:02 2015] [error] SSL Library Error: 218595386 error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error***
Someone know how I can solve this problem?
I need much install this SSL in server.
Assuming you started your proxy container by linking it correctly to your webserver container like:
docker run -d --name webserver ...
docker run -d --name proxy --link webserver ...
When you restart the webserver container its internal Docker IP address might be changed after reboot and the /etc/hosts file on the proxy container gets automatically updated as well. So I guess that when the proxy suddenly connects to a different IP address that breaks SSL.
So you also need to reboot your proxy (or just reload its configuration inside the container if possible to re-initialize the SSL configuration).
I did not test it, yet. But you could also try to define a restart policy on your proxy container like:
docker run -d --name proxy --link webserver --restart=always ...
Related
This all started yesterday after I added a second IP address for port 443 to the "ips and ports" list in Froxlor. As soon as Froxlor's cron job ran, Apache failed to restart. Ever since then, nothing I try will get Apache to stay running with SSL enabled in Froxlor.
System Config:
Ubuntu 20.04.2 LTS (focal)
Apache 2.4.41
Froxlor 0.10.27
Output from sudo systemctl start apache2:
Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xe" for details.
Output from systemctl status apache2.service:
● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2021-07-19 13:33:31 UTC; 41s ago
Docs: https://httpd.apache.org/docs/2.4/
Process: 17629 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE)
systemd[1]: Starting The Apache HTTP Server...
apachectl[17641]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName'>
apachectl[17629]: Action 'start' failed.
apachectl[17629]: The Apache error log may have more information.
systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: apache2.service: Failed with result 'exit-code'.
systemd[1]: Failed to start The Apache HTTP Server.
Output from sudo journalctl -u apache2.service --since today --no-pager:
systemd[1]: Starting The Apache HTTP Server...
apachectl[17169]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
apachectl[17165]: Action 'start' failed.
apachectl[17165]: The Apache error log may have more information.
systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: apache2.service: Failed with result 'exit-code'.
systemd[1]: Failed to start The Apache HTTP Server.
systemd[1]: apache2.service: Unit cannot be reloaded because it is inactive.
"Address already in use" error
Initially I was also getting an error that said apachectl[16500]: (98)Address already in use: AH00072: make_sock: could not bind to address on port 443. Running netstat -anp | grep 443 did not reveal any other processes hogging that port, so I suspected that Apache was trying to use port 443 twice (which tracks with my configuration goof). I managed to get into the database and delete the ip/port record (which had not been assigned to any sites yet) and this particular error went away because Froxlor stopped creating an extra conf file containing Listen 443.
If I comment out both instances of Listen 443 within /etc/apache2/ports.conf, then this particular error goes away but Apache still fails to load.
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf
Listen 80
#<IfModule ssl_module>
# Listen 443
#</IfModule>
#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
(This post with a similar issue offered some insight on this bit)
Output from sudo grep "443" /etc/apache2/*
grep: /etc/apache2/conf-available: Is a directory
grep: /etc/apache2/conf-enabled: Is a directory
grep: /etc/apache2/htpasswd: Is a directory
grep: /etc/apache2/mods-available: Is a directory
grep: /etc/apache2/mods-enabled: Is a directory
/etc/apache2/ports.conf:# Listen 443
/etc/apache2/ports.conf:# Listen 443
grep: /etc/apache2/sites-available: Is a directory
grep: /etc/apache2/sites-enabled: Is a directory
Misc. remarks about Froxlor:
If I comment out \Froxlor\Cron\MasterCron::run(); inside of /var/www/froxlor/scripts/froxlor_master_cronjob.php, then the Froxlor cron job is effectively disabled. Can be useful for troubleshooting, but doesn't fix anything.
Running sudo /usr/bin/php /var/www/froxlor/scripts/froxlor_master_cronjob.php --force will trigger Froxlor to execute its cron job immediately
Current Status:
After many hours of troubleshooting, here is what I know:
when no ip is configured with port 443/SSL, Apache will start.
deleting /etc/apache2/sites-enabled/ directory allows Apache to start, until Froxlor's cron job regenerates it.
likewise, just deleting the *.443.conf files and any ssl.conf files from /etc/apache2/sites-enabled/ also temporarily allows Apache to start (until the Froxlor cron job runs)
removing Froxlor from the server allows Apache to start, but the problem comes back immediately after configuring port 443 within Froxlor.
TLDR: Something broke when I opened Froxlor and added a second IP with a port that was already in use (port 443). Now Apache won't start unless I delete any .conf file involving SSH. Removing Froxlor (including deleting the database) and deleting sites-enabled before reinstalling Froxlor did not resolve the issue.
EDIT: Regenerated my security certificates and now all is good.
Ugh... multitasking bit me again.
Apparently there was something off with the local security certificate. I regenerated it and Apache started working again.
Related post here
Apache (httpd) service is running on RedHat EC2 instance at port 80 and command "curl localhost:80" shows the content of index.html file located at /var/www/html of the apache server.
Below is the output of command "service httpd status", which shows that apache is running and listening on port 80 as well.
Active: active (running) since Thu 2020-01-23 16:25:44 UTC; 24s ago
Docs: man:httpd.service(8)
Main PID: 1651 (httpd)
Status: "Running, listening on: port 80"
I have opened port 80 for http on my EC2 instance.But when i try to access
the apache using http://<Public IP of EC2 Instance>:80
then browser gives message
"This site can’t be reached".
Please let me know why i am unable to access apache using
http://<Public IP of EC2 Instance>:80
and what would be fix to enable me to access it.
curl localhost:80
returns output as below
hello world
curl Public_IP_OF_EC2:80
returns output as below
curl: (7) Failed to connect to *.*.***.172 port 80: No route to host
The security group rule for my Ec2 instance is to accept all traffic which means port 80 for http is open on my EC2 instance.
In a debian 9 server with ISPConfig updated , php 7.3 and lets encrypt. The renew of all certs is ok . But one of them fail when i try to enter the site with https. The browser says that cert is EXPIRED.
I make
/opt/certbot/certbot-auto
i get
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/example.com-0001/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com-0001/privkey.pem
Your cert will expire on 2020-03-10. To obtain a new or tweaked
version of this certificate in the future, simply run certbot-auto
again with the "certonly" option. To non-interactively renew *all*
of your certificates, run "certbot-auto renew"
then
service apache2 restart
ssllabs.com says that the cert is EXPIRED and browser doesn't accept the https connection.
Then i tried to revoke the cert to create a new cert but then fails the apacche server and get this message:
Error while running apache2ctl configtest.
Action 'configtest' failed.
The Apache error log may have more information.
[Wed Dec 11 22:47:54.922290 2019] [alias:warn] [pid 25196] AH00671: The Alias directive in /etc/apache2/conf-enabled/squirrelmail.conf at line 49 will probably never match because it overlaps an earlier Alias.
AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/sites-enabled/000-ispconfig.conf:73
AH00526: Syntax error on line 157 of /etc/apache2/sites-enabled/100-mallata.com.vhost:
SSLCertificateFile: file '/var/www/clients/client3/web3/ssl/example.com-le.crt' does not exist or is empty
From error log you can see your config point to the wrong certificates:
SSLCertificateFile: file '/var/www/clients/client3/web3/ssl/example.com-le.crt' does not exist or is empty
So you should edit /etc/apache2/sites-enabled/100-mallata.com.vhost and edit it to point to the real full chain file /etc/letsencrypt/live/example.com-0001/fullchain.pem and private key /etc/letsencrypt/live/example.com-0001/privkey.pem
Something like:
SSLCertificateFile /etc/letsencrypt/live/example.com-0001/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com-0001/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/example.com-0001/fullchain.pem
I've installing CF2018 on a new server, which is installed and running, I can see it if I run ps aux | ack -i coldfusion
$ cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core)
$ httpd -v
Server version: Apache/2.4.6 (CentOS)
Server built: Jul 29 2019 17:18:49
UPDATE
I had clearly broken something so I've removed earlier errors, but I'm still getting issues with the connector.
I have removed all references and files relating to mod_jk from /etc/httpd/conf, reinstalled CF then re-ran the connector.
It's installed successfully with this command:
$ sudo ./wsconfig -ws Apache -dir /etc/httpd/conf
I have the dir at /opt/coldfusion2018/config/wsconfig/1 setup but I'm now getting these errors:
$ pwd
/opt/coldfusion2018/config/wsconfig/1
$ tail mod_jk.log
[error] ajp_service::jk_ajp_common.c (3000): (cfusion) connecting to tomcat failed (rc=-3, errors=583, client_errors=0).
[info] jk_open_socket::jk_connect.c (816): connect to ::1:8018 failed (errno=13)
[info] ajp_connect_to_endpoint::jk_ajp_common.c (1140): (cfusion) Failed opening socket to (::1:8018) (errno=13)
[error] ajp_send_request::jk_ajp_common.c (1811): (cfusion) connecting to backend failed. Tomcat is probably not started or is listening on the wrong port (errno=13)
[info] ajp_service::jk_ajp_common.c (2979): (cfusion) sending request to tomcat failed (recoverable), because of error during request sending (attempt=1)
[info] jk_open_socket::jk_connect.c (816): connect to ::1:8018 failed (errno=13)
[info] ajp_connect_to_endpoint::jk_ajp_common.c (1140): (cfusion) Failed opening socket to (::1:8018) (errno=13)
[error] ajp_send_request::jk_ajp_common.c (1811): (cfusion) connecting to backend failed. Tomcat is probably not started or is listening on the wrong port (errno=13)
[info] ajp_service::jk_ajp_common.c (2979): (cfusion) sending request to tomcat failed (recoverable), because of error during request sending (attempt=2)
[error] ajp_service::jk_ajp_common.c (3000): (cfusion) connecting to tomcat failed (rc=-3, errors=584, client_errors=0).
I have no idea where port 8018 has come from, I thought tomcat used 8500 by default
UPDATE 2
If I visit my site with :8500 on the end I can get into the CFIDE, so it's CF is running and that port is accessible
UPDATE 3
I've found this in my server.xml file, tried setting the port to both 8009 and 8018 and it seems to make no difference to the errors in the mod_jk.log
<!-- Define an AJP 1.3 Connector on port 8009 -->
<!-- begin connector -->
<Connector port="8009" packetSize="65535" protocol="AJP/1.3" redirectPort="8451" tomcatAuthentication="false" maxThreads="500" connectionTimeout="60000"/>
<!-- end connector -->
Pete,
What's the OS and the webserver's version?
Did you try passing the parameters other than dir, explicitly, like so:
sudo ./wsconfig -ws Apache /opt/apache2/conf -bin /opt/apache2/bin/httpd -script /opt/apache2/bin/apachectl -dir -v
..and the coldfusion process need not be running for the connector to be configured.
8018 is the default AJP port that the conector uses to talk to tomcat. 8500 is the default HTTP port that you'd use when you access the CF admin console.
You initially reported error when configuring the connector. Is that resolved.
Did you check the wsconfig log to see if there were errors configuring the connector.
The modjk log excrepts you've shared more recently simply indicate that CF is not running, or at the least, not listening on the default AJP port.
The problem was SELinux blocking port 8018, I actually asked my hosting provider Secura to look into this for me and they fixed it (based on all the information I'd found from piyush's answer)
I had to allow port 8018 in SELinux
semanage port -a -t http_port_t -p tcp 8018
I installed a general RapidSSL certificate on my Ubuntu 12.04 x64 Apache/iRedMail server at Digital Ocean. It verifies fine in the browser and when I use RapidSSL's checker tool.
However, this server is exclusively for mail, and when I set up an account in Mail (Mac OS) or on my iPhone, etc., I have to make a security exception because it gives me the error "This root certificate is not trusted." And it shows the location as being GuangDong, China for some reason.
I spoke with a support person at eNom (where I bought the SSL certificate) and he mentioned that there might be an issue using the root domain instead of a subdomain for mail, and that I may need a wildcard certificate instead. That suggestion makes no logical sense to me.
My general question is: Is there any difference between setting up a mail server with a general SSL certificate on the root domain, as opposed to a mailserver on a subdomain with a wildcard SSL certificate?
Or is something wrong with my Apache configuration, perhaps?
Thanks! :)
Update:
So now I did the following:
in /etc/dovecot/dovecot.conf
changed:
ssl_cert = </etc/ssl/certs/iRedMail_CA.pem
ssl_key = </etc/ssl/private/iRedMail.key
To:
ssl_cert = </etc/ssl/certificate.crt
ssl_key = </etc/ssl/certificate.key
ssl_ca = </etc/ssl/intermediate.crt
Then in /etc/postfix/main.cf
I changed:
smtpd_tls_cert_file = /etc/ssl/certs/iRedMail_CA.pem
smtpd_tls_key_file = /etc/ssl/private/iRedMail.key
To:
smtpd_tls_cert_file = /etc/ssl/certs/certificate.crt
smtpd_tls_key_file = /etc/ssl/certificate.key
smtpd_tls_CAfile = /etc/ssl/intermeidate.crt
Then, I reboot the server. And Apache hangs, get this error:
root#host:~# service apache2 status
Apache2 is NOT running.
root#host:~# service apache2 restart
* Restarting web server apache2
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
Action 'start' failed.
The Apache error log may have more information.
...fail!
root#host:~#
So, then I do this:
netstat -ltnp | grep ':80'
result:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1464/apache2
Then I do this:
kill -9 1464
And Apache restarts fine after that, but roundcube won't let me log in and I can't connect to IMAP or SMTP at all.
Dovecot log says:
Nov 07 04:31:43 imap-login: Error: SSL private key file is password protected, but password isn't given
Nov 07 04:31:43 imap-login: Fatal: Couldn't parse private ssl_key
Update Again:
Everything in Dovecot is working great now. Had to do the following, since my certificate is encrypted with a password:
killall dovecot
dovecot -p
Then enter my password.
Now my problem is with Postfix, which isn't working at all. I'm assuming it doesn't like the password protected key.
You need to configure dovecot to use SSL.
You have installed and configured SSL only for apache, IMAP/POP/SMTP connections are not handled by apache.
And no, there is no difference in using a domain and subdomain.
How to setup iRedmail to use SSL