Apache reverse proxy ssl handshake fail also AH001897

Question

Here's my setup:

• Apache2 running on Ubuntu 18.
• Certbot running to supply SSL cert
• two dotnet (kestrel) applications listening on https://:5001 and https://:5003
• these two apps have bound to their ssl ports with the same certificate as the apache server, except that it has been converted to pfx format using openssl to combine the key file

The app on port 5003 requires a secure connection to enable user authentication. This app will not work properly through an insecure port even behind Apache's secure connection. Essentially the login cookie gets lost if a login is attempted.

I have tried adding the SSLVerifyClient and or SSLProxyVerify to confim the connection and both will not allow the connection to either of the apps.

Every time I restart Apache I get AH001897 which tells me there are no ca certs known despite the SSLCACertificateFile directive pointing to the bundle in /etc/ssl/certs/ca-certificates.crt.

Certbot produces fullchain.pem as the cert file. I have combined it with privkey.pem to create the pfx file as mentioned above. I have also copied and renamed fullchain.pem to https-le.crt and put it in /usr/share/ca-certificates/dotnet/ folder, changed it's permissions to 644 and used sudo dpkg-reconfigure ca-certificates to add it to the trusted certs. Is this the right course of action???

Can anyone point out what I am doing wrong?

Here's ssl section of my Apache config file:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName <mydomain>
    ServerAlias <mydomain>
    ProxyPreserveHost on

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/<mydomain>/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<mydomain>/privkey.pem

SSLProxyEngine on
SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

    ProxyPass /gnomes https://127.0.1.1:5003/gnomes
    ProxyPassReverse /gnomes https://127.0.1.1:5003/gnomes

    ProxyPass / https://127.0.1.1:5001/
    ProxyPassReverse / https://127.0.1.1:5001/

    ErrorLog ${APACHE_LOG_DIR}mainsite-error.log
    CustomLog ${APACHE_LOG_DIR}mainsite-access.log common

</VirtualHost>
</IfModule>

As recomended I have read the Let's Encrypt link suggested below and have created a self signed cert for localhost. I have then added this to the ca-certificates bulk file (trusted list) and altered the proxy redirects from 127.0.1.1 to localhost.

Below are the log entries with SSLProcyVerify set to require. I note that the errors refer to port 5001 but the actual request should have been redirected to 5003 as the requested url was to mydomain/gnomes/?game=3

[Sat Jun 13 23:03:28.546026 2020] [ssl:error] [pid 23133:tid 139777085007616] [remote 127.0.0.1:5001] AH02039: Certificate Verification: Error (20): unable to get local issuer certificate
[Sat Jun 13 23:03:28.546211 2020] [proxy_http:error] [pid 23133:tid 139777085007616] (103)Software caused connection abort: [client 192.168.1.1:61303] AH01102: error reading status line from remote server localhost:5001, referer: https://<mydomain>/gnomes/?game=3
[Sat Jun 13 23:03:28.551816 2020] [ssl:error] [pid 23134:tid 139777051436800] [remote 127.0.0.1:5001] AH02039: Certificate Verification: Error (20): unable to get local issuer certificate
[Sat Jun 13 23:03:28.551936 2020] [proxy_http:error] [pid 23134:tid 139777051436800] (103)Software caused connection abort: [client 192.168.1.1:61304] AH01102: error reading status line from remote server localhost:5001, referer: https://<mydomain>/gnomes/?game=3
[Sat Jun 13 23:03:28.551969 2020] [proxy:error] [pid 23134:tid 139777051436800] [client 192.168.1.1:61304] AH00898: Error reading from remote server returned by /favicon.ico, referer: https://<mydomain>/gnomes/?game=3

Don't forget that AH001897 is also present every time apache is restarted.

Answer 1

While the following is not strictly the answer to the above, I am posting it as my problem is now solved.

I found that I did not NEED either SSLProxyVerify or SSLVerifyClient because the SSL config was secure enough to enable both apps to work correctly.

I have learned that it wasn't an SSL failure that was causing the authentication failure. The actual problem was that the applications needed to be setup correctly to share the authentication cookie.

My plan was to have a user login to the main application first then get redirected to the second. I had been testing it this way and that was my failure. I discovered that when I logged into the second app first I was not able to login to the first!

This is solved in the code of the apps to point to a common keyfile and have the cookie named correctly.

If you are a dotnet coder and want to learn more here is the question posted on StackOverflow:

https://stackoverflow.com/questions/62273042/blazor-with-ssl-on-ubuntu-and-certbot/62379092#62379092

Answer 2

I had faced similar issues . Then I tried to reverse the certificates sequence by placing root on the top followed by intermediate and server certificate respectively. It had worked.