Certbot setup throwing error for nginx + puma config

I added that to the config before i posted, assuming i did something wrong, the website was inaccessible. I had restarted nginx

And if you place it one step higher? Like this above your location @app?

upstream app {
    # Path to Puma SOCK file, as defined previously
    server unix:/home/ubuntu/application/shared/sockets/puma.sock fail_timeout=0;
}

server {
    listen 80;

    listen 443 ssl;

    server_name poliok.it;

    #ssl_certificate /etc/nginx/ssl/nginx.crt;
    #ssl_certificate_key /etc/nginx/ssl/nginx.key;

    root /home/ubuntu/application/public;

    try_files $uri/index.html $uri @app;

	# ACME Challenge Rule
	location ^~ /.well-known/acme-challenge/ {
	allow all;
    default_type "text/plain";
	}
	
    location @app {
        proxy_pass http://app;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $proxy_host;
        proxy_redirect off; 
    }
    error_page 500 502 503 504 /500.html;
    client_max_body_size 4G;
    keepalive_timeout 10;
}

alright.

i added that, and i also added:
ssl on;
and uncommented the lines where i had self generated the keys for nginx.

I turned on SSL in rails configuration, seems puma config does not seem to need anything to be touched.

When i go to the back end address https://ec2-54-83-129-10.compute-1.amazonaws.com or https://poliok.it

I used chrome in incognito and said to proceed, it seems to forward me to https://app

it has something to do with the proxy_pass config i think in nginx? im not sure what to replace it with? the amazon address?

…almost there!!!

it looks like literal insert of ‘app’ rather than the variable set as upstream in the nginx config. do i need a different way to interpolate it?

I got it working.
ssl on;
ssl_certificate /etc/letsencrypt/live/poliok.it/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/poliok.it/privkey.pem; # managed by Certbot

ssl_session_timeout  5m;

ssl_protocols  SSLv2 SSLv3 TLSv1;
ssl_ciphers  HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers   on;

location @app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
this line -> proxy_set_header X-Forwarded-Proto https;

add to the config file in it’s own code block:
http redirect to https
server {
listen 80;
server_name poliok.it;
return 301 https://$server_name$request_uri;
}

removed listen 80 from SSL block

aand…

I had my godaddy forwarding set up incorrectly, none of the reps prior mentioned it to me. I had it forward and masking to my server when i should i put the aws server static IP into the A-record.

in command line:

certbot-auto --nginx

This fixed it immediately.

This was a journey, hopefully someone who needs it stumbles across this post.

Thank you Andy and thank you Mitchell, really appreciate the help!

You are getting closer, persistence pays off …. sorry replying via email as
the LE community site is currently down.

I tested this morning and the site loads OK in the browser.

You just need to get your TLS settings right as your server is vulnerable
to the Poodle Attack

And you need to get your Ciphers correct using -
https://mozilla.github.io/server-side-tls/ssl-config-generator/

Then if you want to score an A on the securityheaders.io you need to look
into a Content Security Policy but leave that for later until you get the
rest perfect first.

See attached screen grabs.

Kind Regards
Mitchell

Reply: Let’s Encrypt Community Support
letsencrypt+9362d762cae3a09e28b4f48000e267af@discoursemail.com
letsencrypt+9362d762cae3a09e28b4f48000e267af@discoursemail.com

cool info. I updated it from the nginx generator(pulled up my versions and implemented)

I am now only seeing Public Key Pins as an X but I am receiving an A.

I might as well finish it up — what steps would you suggest for updating HPKP?

Avoid HPKP completely, not officially supported, very complex and can
totally brick your domain for good if you mess it up which is very easy to
do.
Live with the A score and wait until HPKP is officially supported by LE
which seems unlikely.

Glad it’s all working now, well done for persevering through it.

KR
Mitchell

Reply: Let’s Encrypt Community Support
letsencrypt+73b5115daba5dcd3f30fc6133b6973d1@discoursemail.com
letsencrypt+73b5115daba5dcd3f30fc6133b6973d1@discoursemail.com

much appreciated, thanks!

And im back.

I am getting issues with inline scripts and css(i believe css too?)
config originally:
add_header Content-Security-Policy "default-src 'self';" always;
now:
add_header Content-Security-Policy "default-src 'none'; script-src 'unsafe-inline'; connect-src 'self'; img-src 'self'; style-src 'unsafe-inline';" always;

I read through the content security policy website documentation and it seems this is recommended starter policy, minus the part that is style-src 'unsafe-inline' and script-src 'unsafe-inline'

I am getting these errors:

The errors were the same regardless of how i configured that header, so I am not sure if i should simply add something like `style-src ‘unsafe-line’; style-src ‘self’;
So I am trying to allow inline css and scripts, I am not 100% what’s the safest way to allow these scripts and block others.

edit:

I tried adding specific domains into the script-src and style-src policies, nginx doesnt complain about the config when i restart the service but it’s still not working as it all the styling and the few inline scripts in the site. Should I pull all these js libraries to the assets and keep it local? This would, I assume, solve all except for the style-src unsafe-inline and script-src unsafe-inline?

any ideas?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.