nginx wordpress sub-domain lets encrypt - wordpress

I ran wordpress site with this SSL tutorial. https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04
I have example.com domain. and I create test.example.com sub-domain.
There's problem with connect with test.example.com it shows NET::ERR_CERT_COMMON_NAME_INVALID on chrome.
How can I connect sub domain to existed lets encrypt. and
further more, How can I connect second-domain example2.com to SSL.

As stated in Let's Encrypt FAQ Let’s Encrypt doesn't offer wildcard certificates:
Let’s Encrypt offers Domain Validation (DV) certificates. We do not
offer Organization Validation (OV), Extended Validation (EV), or
wildcard certificates, primarily because we cannot automate issuance
for those types of certificates.
If you have requested certificate just for example.com it won't work for www.example.com or test.example.com.
You need to explicitly declare every domain or subdomain in your request using -d parameter of letsencrypt or modern certbot:
letsencrypt certonly -a webroot --webroot-path=/var/www/html -d example.com -d test.example.com -d www.example.com
You can request certificate for different domains the same way:
letsencrypt certonly -a webroot --webroot-path=/var/www/html -d example.com -d www.example.com -d example2.com -d www.example2.com

What is your settings on your nginx server directives?
The server directives for both port 80 and port 443 should be refer to the subdomain instead of your domain. Like this:
server {
listen 80;
server_name subdomain.example.com;
return 301 https://subdomain.example.com$request_uri;
}
server {
listen 443 ssl;
server_name subdomain.example.com;
....
}
As for your second domain example2.com, it depends on what you purchased is single-domain SSL certificate or multi-domain certificate.

Related

Nginx Proxy Manager to host site

I am using NPM to configure my subdomains and redirect them to my containers.
My problem is that I cannot do the same with the main domain.
I am using nginx server with php for my site, after configuring a proxy host to test.example.com it is working flawlessly, but if I configure the same for example.com or www.example.com, I am not able to open my site.
I've uploaded my certificate to npm as a custom certificate and assigned it to the example.com proxy host, but it's not working.
If I open http://example.com I get the "Congratulations" page from NPM.
How can I make my site example.com working identical as test.example.com?
I've tried following in my nginx conf:
ssl on;
ssl_certificate /path;
ssl_certificate_key /path;
changing the server_name;

Add domain to generate SSL certificate that is not mentioned in nginx conf for certbot

I generated my SSL certificate for (example) a.com (it was automatically detected in my nginx config). Now, I have another domain b.com pointing to the same ipaddress as a.com but not mentioned in my nginx conf.
How can I generate an SSL certificate for both of these domains using cerbot? If I run certbot it only lets me choose a.com because it is mentioned in my nginx conf but not b.com because its not mentioned.
Thank you.

Generate https with certbot wildcard

how do i generate https for wildcard?
server {
server_name subdomain.domain.com www.subdomain.domain.com *.subdomain.domain.com ~^(.*)\.subdomain\.domain\.com$;
}
currently, for normal domains I generate certificates like this:
sudo certbot --nginx -d example.com
For wildcard just add another entry with *
sudo certbot --nginx -d *.example.com -d example.com
You can further refer here Let's Encrypt: Wildcard Certificate With Certbot
I used following to generate wildcard certificate and it worked like charm. Here we are doing dns challenge hence you should have access to your dns to make entries that will be read while create certificate.
sudo certbot certonly --manual -d *.example.com -d example.com \
--email admin#example.com --agree-tos \
--preferred-challenges dns-01 \
--server https://acme-v02.api.letsencrypt.org/directory
Hope this information will help you
with your command you are issuing a Certificate via HTTP-Challenge. Let's Encrypt doesn't support issuing Wildcard-Certificates via HTTP-Challenge.
Here is a link about challenge types supported by Let's Encrypt:
https://letsencrypt.org/docs/challenge-types/
For Wildcard-certs you need to issue the Certs via DNS-Challenge. Therefore you need API-Access to your hosting provider or dynamic dns provider. Certbot offeres some Plugins for some of them, here is a link to the Certbot-DNS-Plugins-Site: https://certbot.eff.org/docs/using.html#dns-plugins
If your provider isn't listed you can't issue Wildcard-Certs with Certbot. There are some other tools which supports DNS-Challenges for Let's Encrypt like acme.sh, here is a link to the Github-Repository: https://github.com/acmesh-official/acme.sh
I hope I could help you with this information.
Bananenkönig

Nginx Gunicorn socket issue? Unresponsive

I'm trying to deploy a Django project to a AWS Lightsail server.
I followed mostly this tutorial. I added some SSL protocols for additional security.
This projects runs perfectly on my Ubuntu 18.04 VirtualBox with exact same setup and exact same components, same SSL protocols. However on the Lightsail it doesn't respond to the browser request. It will redirect me to https but then will die... I wasn't able to identify any errors in any of the logs. Which leaves me guessing
/etc/systemd/system/webrock.socket:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/webrock.sock
[Install]
WantedBy=sockets.target
/etc/systemd/system/webrock.service:
[Unit]
Description=gunicorn daemon
Requires=webrock.socket
After=network.target
[Service]
User=ubuntu
Group=www-data
WorkingDirectory=/home/ubuntu/django/webrock
ExecStart=/home/ubuntu/django/webrock/venv/bin/gunicorn \
--access-logfile - \
--workers 3 \
--bind unix:/run/webrock.sock \
core.wsgi:application
[Install]
WantedBy=multi-user.target
/etc/nginx/sites-available/webrock:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2 ipv6only=on;
include snippets/signed.conf; # path to certs
include snippets/params.conf; # cert related params
index index.html index.htm index.nginx-debian.html;
server_name mydomain.com www.mydomain.com; #changed this line by replacing domain name with dummy
location = /favicon.ico {access_log off; log_not_found off;}
location /static/ {
root /home/ubuntu/django/webrock;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/webrock.sock;
try_files $uri $uri/ =404;
}
}
server {
listen 80;
listen [::]:80;
server_name mydomain.com www.mydomain.com; #changed this line by replacing domain name with dummy
return 302 https://$server_name$request_uri;
}
I left the nginx default file alone. Now every time I visit the page by punching in the server IP, I see the nginx default page. When I use the domain name I get redirected to HTTPS, but then... nothing. I assume that there is some disruption between gunicorn and nginx, but I'm not experienced enough to troubleshoot there or solve to solve it.
As I mentioned above, exact the same setup runs flawless on the similar system in my VirtualBox.
I'm very thankful for suggestions and hints.
Update:
I disabled the redirect portion in nginx and made it listen to port 80. It worked. Now I'm trying to figure out how to introduce HTTP2 and port 443 back to the setup. BTW my ufw looks like this:
After two days banging my head against this issue here is the solution.
So Amazon Lightsail has an additional firewall in front of the UFW on the actual server.
You can access Lightsail firewall by clicking on...
Menue of your instance > Manage > Networking
You will see a summarized networking for your instance like IP addresses, Firewall, Loadbalancer. In that firewall you need to add an additional port (In my case HTTPS).
Why would they put an additional firewall in front of UFW beats me.

reprocess ssl certbot , when a alias domain fails but certificate is generated, no mode certonly

I've start certbot process with:
sudo certbot --nginx -d example.com -d www.example.com
but I forgot to add 'www.example.com' in 'servernam' nginx virtualsite for example.com
server {
(...)
server_name example.com www.example.com;
(...)
}
then i've got the certificate but not the auto complet process to config my nginx with ssl
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for examle.com
tls-sni-01 challenge for www.example.com
Cleaning up challenges
Cannot find a VirtualHost matching domain www.example.com. In order for Certbot to correctly perform the challenge please add a corresponding server_name directive to your nginx configuration: https://nginx.org/en/docs/http/server_names.html
IMPORTANT NOTES:
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
It's like I wrote just:
cerbot --certonly --standalone -d example.com
because I have just the certificate, now the config on nginx it's ok, i can lauch again the process and overwrite all the old values ? is there a problem with Let's Encrypt Certificate Authority , call again a new certificate for the same domain? what is the solution? delete all again, or complete the rest of process ( nginx config) by hand ?
It's possible with cerbot to launch again the ssl for domains already created. In my case when domains fails, and it's the first time you use certbot. Nginx config is changed but not totally , so when you try second time that will be complet and update nginx config. Certbot just update the config for the domain, and comment the old lines that it think are duplicated and inserting the new ones , addigng #manage by Certbod, so when you need to renovate your certificate Cerbot can change smartly the lines.
Example my nginx config ,with the first try, and second:
if ($scheme != "https") {
return 301 https://$host$request_uri;
} # managed by Certbot
# Redirect non-https traffic to https
# if ($scheme != "https") {
# return 301 https://$host$request_uri;
# } # managed by Certbot

Resources