1

Continuing attempting to configure nginx to use a reverse proxy to radicale that is running on local host and I'm now getting SSL errors having followed the documentation on proxy I created my own SSL certificates.

The relevant section of my nginx configuration is

location /radicale/ {                                                         
          proxy_pass                    http://127.0.0.1:9468/;                     
          #proxy_pass                   http://46.105.31.182:9468/;                 
          proxy_set_header              X-Script-Name /radicale;                    
          proxy_set_header              X-Forwarded-For $proxy_add_x_forwarded_for; 
          proxy_set_header              X-Remote-User $remote_user;                 
          auth_basic                    "Radicale - Password Required";             
          auth_basic_user_file          /etc/radicale/users;                        
          proxy_ssl_verify              on;                                         
          proxy_ssl_certificate         /etc/radicale/client_cert.pem;              
          proxy_ssl_certificate_key     /etc/radicale/client_key.pem;               
          proxy_ssl_trusted_certificate /etc/radicale/server_cert.pem;              
}                                                                             

...and my radicale config for SSL certificates is...

[server]
hosts = 127.0.0.1:9468
ssl = true
certificate = /etc/radicale/server_cert.pem
key = /etc/radicale/server_key.pem
certificate_authority = /etc/radicale/client_cert.pem

[auth]
type = http_x_remote_user
htpasswd_filename = /etc/radicale/users
htpasswd_encryption = bcrypt

If I go to the site https://####/radicale I'm prompted for username and password for authentication, but nginx then returns the following error...

upstream prematurely closed connection while reading response header from upstream, client: 62.253.154.162, server: #####, request: "GEET /radicale/ HTTP/2.0", upstream: "http://127.0.0.1:9468/", host: "####"

...and upstream Radicale reports...

ERROR: An exception occurred during request: SSL handshake failed: [SSL: HTTP_REQUEST] http request (_ssl.c:1076)

If I disable SSL between the reverse proxy on Radicale and nginx then its not a problem, I can access the WebUI https://####/radicale and I can login. But if I enable it then going to https://####/radicale and I get a pop-up box asking me for username/password and the browser reports 502 Bad Gateway and the above errors occur again.

I do have LetsEncrypt certificates in place and working on my domain could this be causing some sort of conflict with the SSL certificates being used for the reverse proxy?

2 Answers 2

2

According to the Nginx documentation proxy_ssl_certificate proxy_ssl_certificate_key are relevant if you want the NGINX identify itself to the upstream servers by using an SSL client certificate provided. You will also need to configure the upstream servers to require client certificates for all incoming SSL connections

I believe Radicale is not handling authentication by client certificate and your Radicale server is listening on 127.0.0.1 so by configuring SSL on Radicale you basically trying to encrypt traffic on localhost.

Another point in your configuration.

location /radicale/ {                                                         
          ...
          auth_basic                    "Radicale - Password Required";             
          auth_basic_user_file          /etc/radicale/users;                        
          ...
}   

Your authentication part is already handled by Radicale itself. There is no point to add these lines on revers proxy.

I suggest to:

  • disable SSL on Radicale and let revers proxy handle SSL with LetsEncrypt.
  • disable basic auth on revers proxy and let Radicale handle user authentication.

If you still want to encrypt traffic between revers proxy and Radicale simply remove client certificate part and add proxy_ssl_name

location /radicale/ {                                                         
          proxy_pass                    http://127.0.0.1:9468/;                     
          #proxy_pass                   http://46.105.31.182:9468/;                 
          proxy_set_header              X-Script-Name /radicale;                    
          proxy_set_header              X-Forwarded-For $proxy_add_x_forwarded_for; 
          proxy_set_header              X-Remote-User $remote_user;  

          proxy_ssl_name                "####";
          proxy_ssl_verify              on;                                                     
          proxy_ssl_trusted_certificate /etc/radicale/server_cert.pem;              
}   

proxy_ssl_name is required to avoid the error

upstream prematurely closed connection while reading response header from upstream, client: 62.253.154.162, server: #####, request: "GEET /radicale/ HTTP/2.0", upstream: "http://127.0.0.1:9468/", host: "####"

This is due to the fact that the name used to be verified against the SSL certificate name is the $proxy_host by default.

6
  • Thanks for the reply, much of what I've used in the config is from the Radicale : Reverse Proxy documentation. I understand why having authentication in two places is unnecessary. Will try your suggestions later on and report back.
    – slackline
    Aug 20, 2019 at 10:54
  • 1
    Went with disabling SSL between nginx and radicale, I can now access the WebUI. Next challenge is getting CalDavx5 to communicate with it. Thanks for your time and advice, very much appreciated.
    – slackline
    Aug 22, 2019 at 5:38
  • @slackline Did you have success? I am also trying to use a reverse proxy with radicale.
    – bomben
    Jan 31, 2021 at 23:07
  • 1
    @Ben Sorry, no I never got it to work for me and abandoned attempting to use Radicale as my email provider (ProtonMail) now have a calendar offering. If I want more privacy in the future I'll probably go with NextCloud which includes calendar functionality along with many other features.
    – slackline
    Feb 2, 2021 at 20:03
  • I worked it out.
    – bomben
    Feb 2, 2021 at 20:11
0

I know this is an old thread, but for the record I got it working like this...

I'm using a separate sub-domain like radicale.example.com, and the script is at / within that, so that's what X-Script-Name is set to. I use letsencrypt/certbot for the certificates.

The nginx stanza is:

server {
    server_name radicale.example.com;
    # (all :80 connections are being redirected to :443)
    listen 443 ssl;                                                                                                                                                           
    listen [::]:443 ssl;                                                                                                                                      
    access_log /var/log/nginx/radicale/access.log main;                                                                                                                                                      
    error_log  /var/log/nginx/radicale/error.log info;                                                                                                                                                                                                                                                                                    
    location / {
            proxy_pass        http://localhost:5232/;
            proxy_set_header  X-Script-Name /;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;                                                                                                                                   
            proxy_set_header  Host $http_host;                                                                                                                                                              
            proxy_pass_header Authorization;                                                                                                                                                                
    }                                                                                                                                                                                                       
    ssl_certificate /etc/letsencrypt/live/radicale.example.com/fullchain.pem; # managed by Certbot                                                                                                             
    ssl_certificate_key /etc/letsencrypt/live/radicale.example.com/privkey.pem; # managed by Certbot                                                                                                           

}

No SSL settings are required within the Radicale config, and I'm letting Radicale handle user passwords.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .