SSL + Bitnami NGINX (maybe really) not configurable

:warning: IMPORTANT, please fill the questions

We assume you are using Bitnami to deploy your application.

  • Which version of the application are you using?:
    Bitnami NGINX Open Source 1.18.0-31 + Bitnami Drupal

  • Please choose how you got the application: Installer (Windows, Linux, macOS), cloud image (AWS, GCE, Azure, …) or VM (VMDK, VBOX):
    Amazon AWS

  • Have you installed any plugin or modified any configuration file?:
    Many

  • Describe here your question/suggestion/issue (expected and actual results):
    I tried to accomplish this
    https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#alternative-approach
    also this
    https://docs.bitnami.com/bch/apps/wordpress-pro/administration/enable-https-ssl-nginx/
    also this
    https://geekflare.com/http2-implementation-apache-nginx/ (which I then deleted because it told me that there was a 443 too many)
    and I also tried to take a look at some other guide (but as you know, if you install nginx from the beginning or packages such as nginx-extra and similar yes ends up having two different nginx that compete with the one provided by Bitnami and therefore I didn’t).
    The result?
    Nginx works as well as the site, but always as before: that is, always if you visit with http, if you visit with https it doesn’t give an answer.

It takes a great deal of patience with Bitnami’s solutions …

  • Steps to reproduce the issue (if relevant):
    e6afa6a5-5bf0-8346-052b-88c786b50258

  • Copy the apache log (if relevant):

PASTE HERE

Hi @dantinoesposito,

I can see the certificate is properly configured and I can access your site using https


Do you want now to force the https redirection? In that case, please share with us the content of the files inside the /opt/bitnami/nginx/conf/server_blocks folder so we can let you know how to modify the configuration

cd /opt/bitnami/nginx/conf/server_blocks
for file in $(ls); do echo $file; cat $file; echo; done

Thanks

Hi @jota

I don’t know how the site shows itself to you and while an error appears to me. Even when clearing the cache, the error reported by Chrome is that of ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

However, for this and for the redirect it also is required, as you request, I am attaching screenshots of what is included in the server_blocks folder.

(please, being an external employee working for this site, I ask that the same url be covered when you post screenshots relating to this, possibly also for the one already published)




Thanks

Hi @dantinoesposito

(please, being an external employee working for this site, I ask that the same url be covered when you post screenshots relating to this, possibly also for the one already published)

Sure!

I have also used Chrome to access the site and did not experience any issues with the SSL. Furthermore, curl does not fail either:

$ curl -IL bXXXXXX.it
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 15 Feb 2021 13:40:02 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://www.XXXXXXX.it/
X-Frame-Options: SAMEORIGIN

HTTP/2 500
server: nginx
content-type: text/html; charset=UTF-8
x-powered-by: PHP/7.4.12
strict-transport-security: max-age=31536000; includeSubDomains
cache-control: must-revalidate, no-cache, private
date: Mon, 15 Feb 2021 13:40:03 GMT
x-ua-compatible: IE=edge
content-language: en
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
expires: Sun, 19 Nov 1978 05:00:00 GMT
x-generator: Drupal 9 (https://www.drupal.org)
x-pass-varnish: YES
x-adv-varnish: Cache-disabled

Actually, the error seems to be with the application, not the certificates.

Best regards,
Jose Antonio Carmona


Was my answer helpful? Click on :heart:

Hi @jcarmona, @jota

I am disappointed with this vague help.

The problem persists and I’m not sure if it’s the influence of the redirect or some configuration or code error in nginx.conf or in the above files.

One thing is certain: I redid all the routes, reinstalled nginx, reinstalled drupal, and as long as you do not proceed with the generation of the ssl certificate (followed all the steps of the Bitnami guide), the site appears on the screen: from that moment the site I can’t see it anymore.

Who can help me to solve without diverting from the problem?
What files do you want me to share?

Thanks

Hi @dantinoesposito

I am disappointed with this vague help.

The problem persists and I’m not sure if it’s the influence of the redirect or some configuration or code error in nginx.conf >or in the above files.

I am sorry to hear that, but I was not able to reproduce the issue on my side. The site (both HTTP and HTTPs) renders fine to me using either Google Chrome, Firefox or Safari. Curl does neither report any issues.

Furthermore, the error you mention (ERR_SSL_VERSION_OR_CIPHER_MISMATCH ) is produced when the server and the client cannot agree with the TLS version or the cipher protocol to use in the HTTPS handshake. This means that both endpoints cannot find a common cryptographic suite to ensure data is transferred securely. As my teammate and I were able to connect the domain with no issues, this is more than likely a misconfiguration/outdated version of your web browser (rather than a very restrictive cryptographic suite policy)

image

Please, ensure your browser supports the above TLS version and cipher suite.

Best regards,
Jose Antonio Carmona


Was my answer helpful? Click on :heart:

I had changed it and now it works but I forgot to tell you the solution.

I have tracked the operations performed, to all those who have problems I recommend checking one or all of the solutions below (I needed them all having made a bit of a mess):

  1. check that the ip address ipv4 is connected to the AWS instance, for the domain there is a dns field AAAA with the ipv6 address of the instance

  2. verify that port 443 is open both on AWS and in the list in response to the “sudo ufw status” command

  3. check that there is some kind of active redirect (example: from www to nowww or vice versa) previously inserted, if you have inserted it in the form of a code block in the https and / or http files in the server_bllocks folder:
    remove any code referencing the redirect from all https files, leave it alone in the drupal-server-block.conf file

(
If you want the redirect, add in the nginx.conf file:
return 301 https: //www.$server_name/$1; -> under “listen 80”
if ($ host = ‘example.com’) {rewrite ^ / (. *) $ https://example.com/$1 permanent; } -> under “error_page 404 502 = @drupal;”
)

  1. check in the same files that the ssl_crtificate and ssl_crtificate_key steps have not been taken, if yes restore the original situation:
    leave only “bitnami / certs / server.crt” and “bitnami / certs / server.key” in the respective files of the server_bllocks folder (they are fine as provided by Bitnami);

  2. check the ssl_protocols field for the nginx.conf file:
    if missing or modified, include all options ie “TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;”

  3. delete the current certificates with probably some errors
    cd bitnami / certs
    sudo rm -rf server.crt server.key

  4. generate new server certificates with:
    openssl req -new -newkey rsa: 2048 -nodes -keyout server.key -out server.crt
    completing all the required information

  5. delete the certificates contained in letsencrypt
    sudo rm -rf / opt / bitnami / letsencrypt
    sudo mv /opt/bitnami/nginx/conf/server.crt.old /opt/bitnami/nginx/conf/server.crt
    sudo mv /opt/bitnami/nginx/conf/server.key.old /opt/bitnami/nginx/conf/server.key
    sudo mv /opt/bitnami/nginx/conf/server.csr.old /opt/bitnami/nginx/conf/server.csr
    sudo /opt/bitnami/ctlscript.sh restart
    and regenerate site certificates following the Bitnami guide
    https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#alternative-approach

  6. finally
    sudo chown root: root / opt / bitnami / nginx / conf / bitnami / certs / server *
    sudo chmod 600 / opt / bitnami / nginx / conf / bitnami / certs / server *
    sudo /opt/bitnami/ctlscript.sh restart nginx
    sudo /opt/bitnami/ctlscript.sh restart

Now works.

Hi @jcarmona and @jota

The problem cannot be considered solved since the homepage appears but all the other pages have a 404 error.

The generation of ssl with nginx is really not configurable to date, on Bitnami solution.

Can you help me, please?

Please @jcarmona and @jota

  1. Launch an AWS instance with Bitnami Nginx
  2. follow the guide https://docs.bitnami.com/installer/how-to/install-drupal-nginx/
  3. follow the guide https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#alternative-approach

You will see that the homepage appears but if you already click on Log in to access Drupal, the link will display a nice 404.

Thanks

Hi @dantinoesposito,

As I just mentioned in your other ticket, we are going to work on reproducing this issue and will update the ticket as soon as we have more information.

Thanks

Hi @dantinoesposito,

I just installed Drupal and didn’t get any error when log in to the application or when clicking on the different links using http.

However, when I generated the SSL certificate and accessed the site using https I reproduced the issue you reported.

After investigating it, I verified that there are missing configuration lines in the drupal-https-server-block.conf file and that’s why you get that 404 error message. You need to include in that file all the location lines you have in the drupal-server-block.conf file. It should look like this

server {
  # Port to listen on, can also be set in IP:PORT format
  listen 443 ssl default_server;
  root /opt/bitnami/drupal;
  # Catch-all server block
  # See: https://nginx.org/en/docs/http/server_names.html#miscellaneous_names
  server_name _;
  ssl_certificate      bitnami/certs/server.crt;
  ssl_certificate_key  bitnami/certs/server.key;
  location = /favicon.ico {
    log_not_found off;
    access_log off;
  }
  location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
  }
  location ~ ^/sites/.*/private/ {
    return 403;
  }
  # Block access to scripts in site files directory
  location ~ ^/sites/[^/]+/files/.*\.php$ {
    deny all;
  }
  # Allow "Well-Known URIs" as per RFC 5785
  location ~* ^/.well-known/ {
    allow all;
  }
  location / {
    try_files $uri /index.php?$query_string;
  }
  location @rewrite {
    rewrite ^/(.*)$ /index.php?q=$1;
  }
  # Don't allow direct access to PHP files in the vendor directory.
  location ~ /vendor/.*\.php$ {
    deny all;
    return 404;
  }
  # Fighting with Styles? This little gem is amazing.
  location ~ ^/sites/.*/files/styles/ {
    try_files $uri @rewrite;
  }
  # Handle private files through Drupal. Private file's path can come
  # with a language prefix.
  location ~ ^(/[a-z\-]+)?/system/files/ {
    try_files $uri /index.php?$query_string;
  }
  location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
    try_files $uri @rewrite;
    expires max;
    log_not_found off;
  }
  location ~ \.php$|^/update.php {
    fastcgi_read_timeout 300;
    fastcgi_pass   unix:/opt/bitnami/php/var/run/www.sock;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME $request_filename;
    fastcgi_split_path_info ^(.+?.php)(|/.*)$;
    include fastcgi_params;
  }
  include  "/opt/bitnami/nginx/conf/bitnami/*.conf";
}

I could access Drupal without problems after restarting NGINX

As you can see, I used https and the certificate is valid for the site.

Note: I’ll ping the documentation team to update the guide as soon as possible.

Thanks

Hello @jota

Glad that the problem is solved.