i have a godaddy ssl Standard certificate, and i have Ubuntu servers running Apache
i follow this page: http://www.codingepiphany.com/2014/11/26/installing-godaddy-ssl-certificate-in-an-ubuntu-server/
and i got apache error:
[Wed Oct 05 03:42:08.986881 2016] [mpm_prefork:notice] [pid 1060] AH00169: caught SIGTERM, shutting down
[Wed Oct 05 03:42:10.011970 2016] [ssl:warn] [pid 6821] AH01909: localhost:443:0 server certificate does NOT include an ID which matches the server name
[Wed Oct 05 03:42:10.013567 2016] [ssl:emerg] [pid 6821] AH02561: Failed to configure certificate dott.com:443:0, check /etc/ssl/gdssl/dott_com.crt
[Wed Oct 05 03:42:10.013618 2016] [ssl:emerg] [pid 6821] SSL Library Error: error:0906D06CSmiley TongueEM routinesSmiley TongueEM_read_bio:no start line (Expecting: CERTIFICATE) -- Bad file contents or format - or even just a forgotten SSLCertificateKeyFile?
[Wed Oct 05 03:42:10.013661 2016] [ssl:emerg] [pid 6821] SSL Library Error: error:140AD009Smiley FrustratedSL routinesSmiley FrustratedSL_CTX_use_certificate_fileSmiley TongueEM lib
AH00016: Configuration Failed
also when i load certificate
openssl x509 -noout -text -in dott_com.crt -modulus | grep Modulus
i got unable to load certificate
also server name is dott.com in godaddy and in config file too
you might want to upload the certificate so someone can check it is actually valid. it may be corrupted or you incorrectly generated it(seems like the name form what the logs and erros are saying).
be sure to keep the private key to yourself!
Related
I have an application running on httpd server under Centos 8. The Apache server requires user to show vaild certificate and than the ssl variables like DN, CN and SERIAL are passed to the Flask application (than the access verification is run).
The app when not vaild cert is given e.g. user's cert is not in database, should show error page under url "/site/public/failed" with proper info.
Problem is that only my cert is passed by Apache and than page loads correctly (My cert is in db), but when my collages (same company, same CA) try to reach it they are flashed with ERR_BAD_SSL_CLIENT_AUTH_CERT and blank page. I assume that even if they will be in db, the Apache wouldn't let them to access app on it.
When I check the logs after them try to connect, it looks different than when I am connecting. One thing that I have spotted is their cert is checked only with depth 0 when my goes to depth 2.
config:
Listen ip:443
##SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
SSLSessionCache shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout 300
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
##SSLCipherSuite PROFILE=SYSTEM
##SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
##SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.3
SSLHonorCipherOrder on
SSLCompression off
WSGIPythonHome /home/path/to/venv
WSGIRestrictStdin Off
WSGIRestrictStdout Off
<VirtualHost ip:443>
ServerName app.com
ErrorLog /etc/httpd/logs/sshproxy-secure.error_log
CustomLog /etc/httpd/logs/sshproxy-secure.access_log ssl_combined
SSLEngine on
SSLCertificateFile /home/path/to/crt.crt
SSLCertificateKeyFile /home/path/to/some_key.key
SSLCACertificateFile /etc/pki/tls/main_ca.crt
SSLCACertificateFile /path/to/more/ca.crt
WSGIDaemonProcess sshproxy threads=20 processes=2 python-path=/home/path/to/venv/lib/python3.10/site-packages
#user=user1 group=group1 threads=5
#WSGIPythonPath /opt/sshproxy/lib/python2.7/site-packages
WSGIScriptAlias / /home/path/to/wsgi-script/sshproxy-webserver-wsgi.py
WSGIScriptReloading On
<Directory /home/path/to/app>
WSGIProcessGroup sshproxy
WSGIApplicationGroup %{GLOBAL}
Require all granted
</Directory>
#<Location />
# SSLRequireSSL
#Require ip 126.16.13.20 126.16.18.
#</Location>
SSLVerifyClient optional
SSLVerifyDepth 5
SSLOptions +StdEnvVars
</VirtualHost>
Error logs when I connect (I deleted some sensitive data, but I believe its not important part of logs):
[Mon Aug 29 08:36:54.406586 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(2330): [client 126.189.244.168:60496] AH02043: SSL virtual host for servername app.com found
[Mon Aug 29 08:36:54.406615 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(2330): [client 126.189.244.168:60496] AH02043: SSL virtual host for servername app.com found
[Mon Aug 29 08:36:54.406629 2022] [core:debug] [pid 17586:tid 140176105887488] protocol.c(2314): [client 126.189.244.168:60496] AH03155: select protocol from , choices=h2,http/1.1 for server app.com
[Mon Aug 29 08:36:59.631867 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(1751): [client 126.189.244.168:60496] AH02275: Certificate Verification, depth 2, CRL checking mode: none (0) [subject:
[Mon Aug 29 08:36:59.632161 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(1751): [client 126.189.244.168:60496] AH02275: Certificate Verification, depth 1, CRL checking mode: none (0) [subject:
[Mon Aug 29 08:36:59.632380 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(1751): [client 126.189.244.168:60496] AH02275: Certificate Verification, depth 0, CRL checking mode: none (0) [subject:
[Mon Aug 29 08:36:59.632679 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(2246): [client 126.189.244.168:60496] AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_128_GCM_SHA256 (128/128 bits)
[Mon Aug 29 08:36:59.633566 2022] [ssl:debug] [pid 17586:tid 140176105887488] ssl_engine_kernel.c(383): [client 126.189.244.168:60496] AH02034: Initial (No.1) HTTPS request received for child 204 (server domain:443)
[Mon Aug 29 08:36:59.633893 2022] [authz_core:debug] [pid 17586:tid 140176105887488] mod_authz_core.c(820): [client 126.189.244.168:60496] AH01626: authorization result of Require all granted: granted
[Mon Aug 29 08:36:59.633925 2022] [authz_core:debug] [pid 17586:tid 140176105887488] mod_authz_core.c(820): [client 126.189.244.168:60496] AH01626: authorization result of <RequireAny>: granted
Error logs when they connect:
[Tue Aug 30 11:01:41.293387 2022] [ssl:debug] [pid 24609:tid 140421665646336] ssl_engine_kernel.c(2330): [client 126.189.44.235:57122] AH02043: SSL virtual host for app.com
[Tue Aug 30 11:01:41.293496 2022] [ssl:debug] [pid 24609:tid 140421665646336] ssl_engine_kernel.c(2330): [client 126.189.44.235:57122] AH02043: SSL virtual host for app.com
[Tue Aug 30 11:01:41.293519 2022] [core:debug] [pid 24609:tid 140421665646336] protocol.c(2314): [client 126.189.44.235:57122] AH03155: select protocol from , choices=h2,http/1.1 for server
[Tue Aug 30 11:01:41.476727 2022] [ssl:debug] [pid 24609:tid 140421665646336] ssl_engine_kernel.c(1751): [client 126.189.44.235:57122] AH02275: Certificate Verification, depth 0, CRL checking m
[Tue Aug 30 11:01:41.476860 2022] [ssl:info] [pid 24609:tid 140421665646336] [client 126.189.44.235:57122] AH02276: Certificate Verification: Error (66): EE certificate key too weak [subject: e
[Tue Aug 30 11:01:41.476988 2022] [ssl:info] [pid 24609:tid 140421665646336] [client 126.189.44.235:57122] AH02008: SSL library error 1 in handshake (server domain:443)
[Tue Aug 30 11:01:41.477100 2022] [ssl:info] [pid 24609:tid 140421665646336] SSL Library Error: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
[Tue Aug 30 11:01:41.477120 2022] [ssl:info] [pid 24609:tid 140421665646336] [client 126.189.44.235:57122] AH01998: Connection closed to child 194 with abortive shutdown (server napupp19.corpne
[Tue Aug 30 11:01:44.545107 2022] [ssl:info] [pid 24609:tid 140421573326592] [client 126.189.44.235:57125] AH01964: Connection to child 205 established (server domain:443)
[Tue Aug 30 11:01:44.545572 2022] [socache_shmcb:debug] [pid 24609:tid 140421573326592] mod_socache_shmcb.c(532): AH00835: socache_shmcb_retrieve (0xea -> subcache 10)
[Tue Aug 30 11:01:44.545621 2022] [socache_shmcb:debug] [pid 24609:tid 140421573326592] mod_socache_shmcb.c(917): AH00851: shmcb_subcache_retrieve found no match
[Tue Aug 30 11:01:44.545634 2022] [socache_shmcb:debug] [pid 24609:tid 140421573326592] mod_socache_shmcb.c(542): AH00836: leaving socache_shmcb_retrieve successfully
I don't know what's the reason why their cert is checked starting at depth 0, while mine is from depth 2?
Changing cipher string = default#seclevel=2 to cipher string = default#seclevel=1 in openssl.cnf file has resolved problem. Nonetheless I don't know why my cert was passed while others didn't. We all have standardized token with cert, so they all should have similar sec level.
Hi I am trying to create a python file that reloads apache2 the code of this file is:
import os
os.system("service apache2 reload")
When I use the command in the terminal everything works fine but when I run the python script I got this error:
Job for apache2.service failed.
See "systemctl status apache2.service" and "journalctl -xe" for details.
so I checked the journalctl and got this:
nov 29 13:50:19 gerrietech apachectl[37415]: Action 'graceful' failed.
nov 29 13:50:19 gerrietech apachectl[37415]: The Apache error log may have more information.
end this comes out of the error log:
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 192.168.50.183. Set the 'ServerName' directive globally to suppress this message
[Mon Nov 29 13:37:35.533656 2021] [mpm_prefork:notice] [pid 36741] AH00163: Apache/2.4.46 (Ubuntu) OpenSSL/1.1.1f configured -- resuming normal operations
[Mon Nov 29 13:37:35.533672 2021] [core:notice] [pid 36741] AH00094: Command line: '/usr/sbin/apache2'
[Mon Nov 29 13:38:23.180736 2021] [mpm_prefork:notice] [pid 36741] AH00169: caught SIGTERM, shutting down
[Mon Nov 29 13:38:45.809351 2021] [mpm_prefork:notice] [pid 37219] AH00163: Apache/2.4.46 (Ubuntu) OpenSSL/1.1.1f configured -- resuming normal operations
[Mon Nov 29 13:38:45.809422 2021] [core:notice] [pid 37219] AH00094: Command line: '/usr/sbin/apache2'
How do i fix this?
After i used /etc/init.d/apache2 reload instead of service apache2 restarti dont get any errors and the script does what it is supposed to do
I'm running a Bitrix server over a CentOS Linux 7.4.1708 machine and I can't manage to get Apache work properly. I've tried restarting the Apache service but it didn't work.
I've checked the system logs via Webadmin and it shows the following:
[Mon Mar 05 03:33:12.118466 2018] [mpm_prefork:notice] [pid 1351]
AH00163: Apache/2.4.6 (CentOS) PHP/7.0.26 OpenSSL/1.0.2k-fips
configured -- resuming normal operations
[Mon Mar 05 03:33:12.118482 2018] [core:notice] [pid 1351] AH00094:
Command line: '/usr/sbin/httpd -D FOREGROUND'
[Mon Mar 05 11:19:46.641040 2018] [mpm_prefork:notice] [pid 1351]
AH00170: caught SIGWINCH, shutting down gracefully
[Mon Mar 05 11:20:15.021546 2018] [suexec:notice] [pid 1360] AH01232:
suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Mar 05 11:20:15.107376 2018] [so:warn] [pid 1360] AH01574: module
socache_shmcb_module is already loaded, skipping
[Mon Mar 05 11:20:17.068083 2018] [mpm_prefork:notice] [pid 1360]
AH00163: Apache/2.4.6 (CentOS) PHP/7.0.26 OpenSSL/1.0.2k-fips
configured -- resuming normal operations
[Mon Mar 05 11:20:17.068138 2018] [core:notice] [pid 1360] AH00094:
Command line: '/usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -D
FOREGROUND'
[Mon Mar 05 11:36:43.537842 2018] [mpm_prefork:notice] [pid 1360]
AH00170: caught SIGWINCH, shutting down gracefully
[Mon Mar 05 11:37:13.314311 2018] [suexec:notice] [pid 1351] AH01232:
suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Mar 05 11:37:13.351957 2018] [so:warn] [pid 1351] AH01574: module
socache_shmcb_module is already loaded, skipping
[Mon Mar 05 11:37:15.361335 2018] [mpm_prefork:notice] [pid 1351]
AH00163: Apache/2.4.6 (CentOS) PHP/7.0.26 OpenSSL/1.0.2k-fips
configured -- resuming normal operations
[Mon Mar 05 11:37:15.361360 2018] [core:notice] [pid 1351] AH00094:
Command line: '/usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -D
FOREGROUND'
[Mon Mar 05 11:49:01.192086 2018] [mpm_prefork:error] [pid 1351]
AH00161: server reached MaxRequestWorkers setting, consider raising
the MaxRequestWorkers setting
[Mon Mar 05 12:01:13.778293 2018] [mpm_prefork:notice] [pid 1351]
AH00170: caught SIGWINCH, shutting down gracefully
[Mon Mar 05 12:01:43.297586 2018] [suexec:notice] [pid 1383] AH01232:
suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Mar 05 12:01:43.371237 2018] [so:warn] [pid 1383] AH01574: module
socache_shmcb_module is already loaded, skipping
[Mon Mar 05 12:01:44.932973 2018] [mpm_prefork:notice] [pid 1383]
AH00163: Apache/2.4.6 (CentOS) PHP/7.0.26 OpenSSL/1.0.2k-fips
configured -- resuming normal operations
[Mon Mar 05 12:01:44.933001 2018] [core:notice] [pid 1383] AH00094:
Command line: '/usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -D
FOREGROUND'
I don't have any clue on what the problem might be. Apache used to work fine until we installed a Bitrix update on the server.
Any sort of help or comment about this would be much appreciated.
Did you increase the MaxRequestWorkers setting as suggested in the logs?
Find the corresponding file:
grep -Ril MaxRequestWorkers /etc/httpd/
On CentOS usually it is /etc/httpd/conf/httpd.conf. Open the file, increase the value of MaxRequestWorkers and restart the web server for the changes to take effect:
systemctl restart httpd
Apache Virtual Host documentation:
If you are trying to debug your virtual host configuration, you may find the Apache -S command line switch useful. That is, type the following command:
/usr/local/apache2/bin/httpd -S
This command will dump out a description of how Apache parsed the configuration file. Careful examination of the IP addresses and server names may help uncover configuration mistakes. (See the docs for the httpd program for other command line options)
# /usr/local/apache2/bin/httpd -S
bash: /usr/local/apache2/bin/httpd: No such file or directory
# find / -type f -iname apache2
/etc/monit/monitrc.d/apache2
/etc/init.d/apache2
/etc/default/apache2
/etc/logrotate.d/apache2
/etc/bash_completion.d/apache2
/etc/cron.daily/apache2
/usr/share/php5/sapi/apache2
/usr/share/lintian/overrides/apache2
/usr/sbin/apache2
# /usr/sbin/apache2 -S
[Tue Jul 19 15:18:49.663497 2016] [core:warn] [pid 3766] AH00111: Config variable ${APACHE_LOCK_DIR} is not defined
[Tue Jul 19 15:18:49.663887 2016] [core:warn] [pid 3766] AH00111: Config variable ${APACHE_PID_FILE} is not defined
[Tue Jul 19 15:18:49.664071 2016] [core:warn] [pid 3766] AH00111: Config variable ${APACHE_RUN_USER} is not defined
[Tue Jul 19 15:18:49.664244 2016] [core:warn] [pid 3766] AH00111: Config variable ${APACHE_RUN_GROUP} is not defined
[Tue Jul 19 15:18:49.664428 2016] [core:warn] [pid 3766] AH00111: Config variable ${APACHE_LOG_DIR} is not defined
[Tue Jul 19 15:18:49.684790 2016] [core:warn] [pid 3766] AH00111: Config variable ${APACHE_RUN_DIR} is not defined
[Tue Jul 19 15:18:49.685433 2016] [core:warn] [pid 3766] AH00111: Config variable ${APACHE_LOG_DIR} is not defined
AH00526: Syntax error on line 74 of /etc/apache2/apache2.conf:
Invalid Mutex directory in argument file:${APACHE_LOCK_DIR}
So, what should I be typing instead of /usr/local/apache2/bin/httpd -S on Debian 8 with Apache 2.4.10 ?
My system:
# lsb_release -da
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.1 (jessie)
Release: 8.1
Codename: jessie
Turnkey LAMP Debian 8 Core 14.1 LAMP Stack - Web Stack (MySQL)
$ apache2 -v
Server version: Apache/2.4.10 (Debian)
Server built: Aug 1 2015 20:53:57
The error message I gen when I try to access the web page server "192.168.50.29/cgi-bin/tinyPL.cgi"; looks like this:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, root#localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache/2.2.11 (Fedora) Server at 192.168.50.29 Port 80
Error_log :
[Sat Oct 24 21:30:47 2009] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Oct 24 21:30:47 2009] [notice] Digest: generating secret for digest authentication ...
[Sat Oct 24 21:30:47 2009] [notice] Digest: done
[Sat Oct 24 21:30:48 2009] [notice] Apache/2.2.11 (Unix) DAV/2 PHP/5.2.9 mod_ssl/2.2.11 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations
[Sat Oct 24 21:30:50 2009] [error] [client 192.168.50.69] (13)Permission denied: exec of '/var/www/cgi-bin/tinyPL.cgi' failed
[Sat Oct 24 21:30:50 2009] [error] [client 192.168.50.69] Premature end of script headers: tinyPL.cgi
Could any one help me on this!
Your log file will have more details regarding the error, but an Internal Server error on a CGI script usually means that when the server tried to execute your CGI program the expected headers was not present.
In a perl script, that would be (for example):
use CGI qw(:standard);
print header();
Which will print out something like:
Content-type: text/html
Try and run your CGI script from the commandline and see if prints out those lines. The other problem might be due to access permissions. Apache might not be able to execute your script.