SSLCACertificatePath: directory does not exist

Help
41

Here is a clue to your performance problem. It is beyond scope of this forum to resolve those but maybe this helps anyway

curl -i www.nuage.dennet.eu/index.php/login

HTTP/1.1 504 Gateway Timeout
Date: Sat, 25 Feb 2023 15:53:56 GMT
Server: Apache/2.4.55 (Fedora Linux) OpenSSL/3.0.8 mod_perl/2.0.12 Perl/v5.36.0
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: none
(other headers omitted)

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>504 Gateway Timeout</title>
</head><body>
<h1>Gateway Timeout</h1>
<p>The gateway did not receive a timely response
from the upstream server or application.</p>
</body></html>
3 Likes
42

:smiley: Thanks.

3 Likes
43

Do you Know what ? I had reboot the vps, then httpd. Then it did not work : I mean from client side I had error something like ssl_something_too_long. Ok. So turn around this and finally I had an other error. I checked SSL Server Test: www.nuage.dennet.eu (Powered by Qualys SSL Labs) which say

No secure protocols supported

And they explain in this case

if you get this message, but you know that the site supports SSL, wait until the cache expires on its own, then try again, making sure the hostname you enter uses the "www" prefix

Right, I waited, no changes, of course. But then, certbot had set up a file ssl.conf, that include these parameters :

SSLProtocol all -SSLv3 SSLProxyProtocol all -SSLv3

So I activated that ssl.conf file. Since then I have again the first error I had :

SSLCertificateFile: file '/etc/letsencrypt/live/www.nuage.dennet.eu/fullchain.pem' does not exist or is empty

The behaviour, don't know if it's from httpd or openssl part, is not stable isn't it ? There might be a bug somewhere no ?

Just to mantion that I have read also Unable to establish SSL connection: wrong version number
He also have a problem of version... but finally have to deal with a "default server" (I do not understand everything I should say). But for me the error reporting of ssl is messy. In fact you do not get the error code of the problem you are facing, and more than that for given config files in http you could have something working... one day... and not working after simple reboot.

44

What do these show?

sudo httpd -S

sudo systemctl status httpd

The "wrong version number" is because your port 443 VirtualHost for that domain is configured for HTTP (not HTTPS). Just like in the thread you linked to

(Using http for port 443 should not work, but it does)
curl -i http://www.nuage.dennet.eu:443

HTTP/1.1 200 OK
Date: Sun, 26 Feb 2023 13:32:28 GMT
Server: Apache/2.4.55 (Fedora Linux) OpenSSL/3.0.8 mod_perl/2.0.12 Perl/v5.36.0

<!doctype html>
<title>Site Maintenance</title>
<style>
3 Likes
45 
VirtualHost configuration:
217.182.71.134:443     is a NameVirtualHost
         default server www.nuage.dennet.eu (/etc/httpd/conf.d/2-nuage-le-ssl.conf:1)
         port 443 namevhost www.nuage.dennet.eu (/etc/httpd/conf.d/2-nuage-le-ssl.conf:1)
                 alias nuage.dennet.eu
         port 443 namevhost dokuden.dennet.eu (/etc/httpd/conf.d/3-dokuden-le-ssl.conf:1)
                 alias www.dokuden.dennet.eu
217.182.71.134:80      is a NameVirtualHost
         default server www.polhypro.dennet.eu (/etc/httpd/conf.d/1-polhypro.conf:1)
         port 80 namevhost www.polhypro.dennet.eu (/etc/httpd/conf.d/1-polhypro.conf:1)
                 alias polhypro.dennet.eu
         port 80 namevhost www.nuage.dennet.eu (/etc/httpd/conf.d/2-nuage.conf:2)
                 alias nuage.dennet.eu
         port 80 namevhost dokuden.dennet.eu (/etc/httpd/conf.d/3-dokuden.conf:2)
                 alias www.dokuden.dennet.eu
         port 80 namevhost www.dennet.dennet.eu (/etc/httpd/conf.d/4-dennet.conf:1)
                 alias dennet.dennet.eu
ServerRoot: "/etc/httpd"
Main DocumentRoot: "/var/www"
Main ErrorLog: "/etc/httpd/logs/error_log"
Mutex authdigest-client: using_defaults
Mutex lua-ivm-shm: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex authn-socache: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/etc/httpd/run/" mechanism=default
Mutex cache-socache: using_defaults
Mutex authdigest-opaque: using_defaults
Mutex watchdog-callback: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
PidFile: "/etc/httpd/run/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
Define: MODPERL2
User: name="apache" id=48
Group: name="apache" id=48

 sudo systemctl status httpd
 httpd.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/httpd.service.d
             └─php-fpm.conf
     Active: active (running) since Sun 2023-02-26 09:17:48 UTC; 23h ago
       Docs: man:httpd.service(8)
   Main PID: 1795 (/usr/sbin/httpd)
     Status: "Total requests: 1604; Idle/Busy workers 100/0;Requests/sec: 0.0187; Bytes served/sec: 1.2KB/sec"
      Tasks: 230 (limit: 4506)
     Memory: 33.4M
        CPU: 57.729s
     CGroup: /system.slice/httpd.service
             ├─1795 /usr/sbin/httpd -DFOREGROUND
             ├─1796 /usr/sbin/httpd -DFOREGROUND
             ├─1797 /usr/sbin/httpd -DFOREGROUND
             ├─1798 /usr/sbin/httpd -DFOREGROUND
             ├─1799 /usr/sbin/httpd -DFOREGROUND
             └─1993 /usr/sbin/httpd -DFOREGROUND

févr. 26 09:17:48 vps-395cf409.vps.ovh.net systemd[1]: Starting httpd.service - The Apache HTTP Server...
févr. 26 09:17:48 vps-395cf409.vps.ovh.net httpd[1795]: Server configured, listening on: port 443, port 8080, ...
févr. 26 09:17:48 vps-395cf409.vps.ovh.net systemd[1]: Started httpd.service - The Apache HTTP Server

Ha did know, I thought typing http://.......................:443 lead to the same than https://
In the :80 virtualhosts, to be ablae to make it works only in http mode, I had disabled the lines rewrite (I think it is not necessary to overload the net with https when the pages are opened only for consultation (like sharing a simple doc or reading a dokuwiki).

I would like to able to resolve this on my own, but I do not have the knowledge, so thanks a lot to help again.

Right now, I had changed the conf files of httpd, so these results are the ones of an other versions of these files. With the new ones I am, again, not able to parse the files and restart httpd. And, of course :roll_eyes: I do not use git to follow the changes in these files (which, by the way, could be interesting :thinking: ...

46

Now show the contents of this file. Put 3 backticks before and after to ensure we see all of it

Like:
```
contents of file
```

4 Likes
47

Er... not sure if it is safe to put all the config here ... ? So I had made a https://apaste.info/c3gF available for a week. Is this ok for you ? I had put in it all files I found interesting.
These are files in /etc/httpd/conf/httpd.conf ; etc/httpd/conf.d/ports.conf ans ssl.conf that have been parsed and work on the server right now;
The files regarding «nuage» vhost which have been changed since the last successful start of httpd (but I do not have the version which where parsed at that time). There 3 other sites, with config files in the same template, would have it also ?
I can remove all files related to ssl, and start again the server, and give you access via server-info ( mod_info - Apache HTTP Server Version 2.4 ) ? At least to have an overview ot the server without ssl as a basis and make sure it is correct.

48

Those Apache config files are not the ones handling requests to your domain.

Why do I say this? Because there are no redirects in the port 80 VHost for nuage.dennet.eu. Further, there are numerous http response headers that are not set in those configs so what sets them? The home page redirects to a .php but I don't see any of the typical config settings for php.

So, are you sure this Apache is the one handling the requests? Is there some sort of routing in your network config or hosting setup that sends requests to a different Apache? Multiple conflicting Apache's is one explanation for the kinds of problems you have shown.

The below curl, based on the latest VirtualHost you showed, should not redirect but it does:

curl -i http://nuage.dennet.eu
HTTP/1.1 302 Found
Date: Tue, 28 Feb 2023 14:27:44 GMT
Server: Apache/2.4.55 (Fedora Linux) OpenSSL/3.0.8 mod_perl/2.0.12 Perl/v5.36.0
X-Powered-By: PHP/8.1.15
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-VmdrVGJaeVNYZndOWGkzeDFsRDFFL1pUd3cxd3RMZGhMb2FDUWl3Z0oxaz06SnpCcUo5SDJhb3hVQ1VHd3R4eTJJNndWOWxjRzlvSUNSdXpuZTNZVmRSZz0='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: oc_sessionPassphrase=HIccom%2BCICKMbi6wUcA87jlDESfOXtx1bostQs8t5uO9Tiga3TD%2FhWt3sXiK0aOQNsdk7EYuTL44neznGtmwhcNgKd7U%2FXI2Vq5BA2rrBef7BrG41bXzusaRtcpXJaw%2F; path=/; HttpOnly; SameSite=Lax
Set-Cookie: nc_sameSiteCookielax=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
Set-Cookie: nc_sameSiteCookiestrict=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
Set-Cookie: ocgwcnwkd8j5=7969iqkkdonmf7ghbnu3431vk7; path=/; HttpOnly; SameSite=Lax
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: none
X-XSS-Protection: 1; mode=block
Location: http://www.nuage.dennet.eu/index.php/login
Content-Length: 0
Content-Type: text/html; charset=UTF-8
3 Likes
49

No because I disabled the lines redirecting to https, since I want to be able to access the site without https.

I do not understand what are http response headers ? I have found this page : mod_headers - Apache HTTP Server Version 2.4 After reading it I should say I've never heard about and for instance I do not understand everything on how and what headers to set. But I will study that. For now the module is called into

/etc/httpd/conf.modules.d/00-base.conf:LoadModule headers_module modules/mod_headers.so

And might be not used, don't know. On the old vps I did not set any headers as well but it was working.

The index in httpd.conf include the process of .php files. Then into nuage (nextcloud), or polhypro (site with drupal) there are config.php files. Is this what you are talking about ?

As far as I know yes. I had stopped the Apache on other vps (no longer used and removed today). There is only one server linked to this IP address, and only one instance of httpd on that server with only these files to configure it. So... what can I say ? These files where the ones used on the other vps that I copied on that one (adapting the IP of course). The old vps was working both http and htpps (OS : centos).

This I can explain : as I said, the server was working for http. Not https. Then, I had changed the files, for example commented the redirections to https in virtualhost *:80. Then I tried to parse the config files but it doesn't, refusing to parse the new config files because of the error about "liles does not exeist or empty". Then there is a discrepancy between the config of the server and the config files I show you regarding virtualhost. Only http.conf, ssl.conf and ports.conf are the same. Hope to be clear...?
.... writing this I thought I could restart, may be the server, even if the apachectl configtest gives an error. So I just did it and httpd restarted.... so it can parse config files even if there is errors in it ? Anyway the curl -i gives the same. But what's wrong ? The redirect from

http://nuage.dennet.eu -> Location: http://www.nuage.dennet.eu/index.php/login

? I guess it is something into the nextcloud files ...?
May be you can also try this :

curl -i https://www.polhypro.dennet.eu
curl: (60) SSL: no alternative certificate subject name matches target host name 'www.polhypro.dennet.eu'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Without https, say curl -i http://www.polhypro.dennet.eu you get the right page.

50

This will fail:

Because there is no HTTPS vhost that covers that name [and likely no certificate either].

3 Likes
51

Are you using sudo apachectl configtest ?

Also, if you see redirects even with the redirects commented out you have a fundamental Apache management problem. Somehow you have multiple configs or multiple Apache. On some other day I might be interested to help but my schedule right now does not allow as much time as it will require. Best of luck to you.

3 Likes
52

Thanks, it was lot of help. I will remove everything and start from scratch.

2 Likes
53

I did a certbot run for this domain and a config file for it which is almost the same as nuage.dennet.eu so the bahaviour shall be the same for both.
Well, it becomes clear for both of you that the problem is myself. So, I will take everything from 0, again, cause apparently, copying what I did 5 years ago on the other server (that I forgot), to paste on the new one wasn't a good idea or wasn't done properly.

Thanks all of you, I really appreciate your patience.

2 Likes
54

@MikeMcQ & @rg305 I come back to tell that I have identified the problem (I think) :thinking:
Into the main config files I called the optional conf.d/files.conf at the begining. But, as mentioned here https://httpd.apache.org/docs/2.4/sections.html the order of parsing instructions, directives, etc..., indeed files included is important.

So I had rewritten totally the http.conf file and now everything works. Or almost I just have an error

TLSv1.3 (IN), TLS alert, unknown (628):

  • OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0
  • Closing connection 0
    curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0

But at least with curl I see the port 443 opened and handshakes works :

 successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=www.nuage.dennet.eu
*  start date: Feb 22 12:36:52 2023 GMT
*  expire date: May 23 12:36:51 2023 GMT
*  subjectAltName: host "nuage.dennet.eu" matched cert's "nuage.dennet.eu"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: nuage.dennet.eu
> User-Agent: curl/7.74.0
> Accept: */*

It should not be a big issue now. I'll find it :smiley:

1 Like
55

If you care to share the config...
6 :eyes: are better than 2 - LOL

Probably something simple - like: turning SSL on in that vhost

2 Likes
56

Of course, I just did not want to bother you again. I put it all here http://www.dennet.dennet.eu/server-info

Oups ... you said

I thought about
Include /etc/letsencrypt/options-ssl-apache.conf
which was into the old config file, but I do not know why. There is no file corresponding in my system actually.

57

Hello @Denis4l I am unable to connect to your link; hopefully it is only me and my location.
Well now I am able to connect to your link. :slight_smile:

58

If you try to open https://nuage.dennet.eu the error log shows :

[ssl:info] [pid 10414:tid 10462] [client 88.142.37.77:60722] AH01964: Connection to child 212 established (server www.nuage.dennet.eu:443)
[Fri Mar 03 20:05:53.301462 2023] [ssl:debug] [pid 10414:tid 10462] ssl_engine_kernel.c(2395): [client 88.142.37.77:60722] AH02043: SSL virtual host for servername nuage.dennet.eu found
[Fri Mar 03 20:05:53.301574 2023] [core:debug] [pid 10414:tid 10462] protocol.c(2460): [client 88.142.37.77:60722] AH03155: select protocol from , choices=h2,http/1.1 for server www.nuage.dennet.eu
[Fri Mar 03 20:05:53.544207 2023] [ssl:info] [pid 10414:tid 10462] [client 88.142.37.77:60722] AH02008: SSL library error 1 in handshake (server www.nuage.dennet.eu:443)
[Fri Mar 03 20:05:53.544268 2023] [ssl:info] [pid 10414:tid 10462] SSL Library Error: error:0A0000C7:SSL routines::peer did not return a certificate -- No CAs known to server for verification?
[Fri Mar 03 20:05:53.544279 2023] [ssl:info] [pid 10414:tid 10462] [client 88.142.37.77:60722] AH01998: Connection closed to child 212 with abortive shutdown (server www.nuage.dennet.eu:443)

How do you understand that in one hand, here above, the log from httpd says something like "no certificate returned for handshake", while on the other hand with curl the handshake ok, SSL certificate verify ok..... and then alert certificate required, errno 0 ?

How do you analyse this ? :face_with_raised_eyebrow:

Wonder if I'd better open another topic cause the initial one about file which doesn't exist is solved.

59

Looks like you`re requiring client certificates to access the site?

2 Likes
60

I missed this post. I thought it was the same as a similar one...

This was never answered. Can you share why you are using this directive?

There are very few situations where SSLCACertificatePath is used. Are you sure you are supposed to use this? What is your goal and purpose of using SSLCACertificatePath and configuring your server to use LetsEncrypt certificates as Client and not Server certificates?

SSLCACertificatePath is one of the directives for requiring Client Certificates. it has no other use, aside from requiring Client Certificates.

4 Likes