I just installed iredmail on my VPS, and tried to install my ssl certificates. To do so I am modifying /etc/nginx/templates/ssl.tmpl to use these these lines instead of the self signed certificate:
ssl_certificate /etc/ssl/certs/vendify-ssl-certificate.pem;
ssl_certificate_key /etc/ssl/private/vendify-ssl-private-key.pem;
ssl_client_certificate /etc/ssl/certs/vendify-CA-CF-Cert.pem;
ssl_verify_client on;
However, when I do this, I get 400 Bad Request No required SSL certificate was sent and when I disable the ssl_verify_client on on my /etc/nginx/templates/ssl.tmpl, this error dissapears, but obviously, the certificate is not trusted, since it cannot be verified. I have enabled authenticated origin pulls on cloudflare's end, but this error still persists.
Thanks!
Related
I'm experiencing a strange issue when requesting Let's Encrypt certificates for a Next.js app hosted with Nginx reverse proxy.
I personally have a dedicated Nginx reverse proxy config template for configuring subdomains, which I used to configure web servers for multiple apps and subdomains:
server {
server_name subdomain.example.com;
location / {
proxy_pass http://localhost:8888;
include /etc/nginx/proxy_params;
}
access_log /var/log/nginx/example-subdomain.log;
error_log /var/log/nginx/example-subdomain-error.log crit;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
listen 80;
}
However, when running sudo certbot --nginx -d subdomain.example.com, certbot fails with the following log. Note that this is the very first time I've encountered such an error, especially as both config and command were working successfully in my previous attempts.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for subdomain.example.com
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: quantumteknologi.com
Type: unauthorized
Detail: 2400:6180:0:d0::15f6:1001: Invalid response from http://subdomain.example.com/.well-known/acme-challenge/hYZEXfMlhq-UDKblyOM2kXk_y-bbNJ5NOzTQly1AXeo: 404
Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
After further investigation the requested http://subdomain.example.com/.well-known/acme-challenge/hYZEXfMlhq-UDKblyOM2kXk_y-bbNJ5NOzTQly1AXeo is indeed not found, as Nginx simply passes the request into the Next.js application I built, instead of intercepting it and return it with proper response to continue my Let's Encrypt application.
Is there something wrong with my Nginx config? Or are there any missing steps which I've followed?
I have three files regarding certificates:
- example.com.ca-bundle # contains root and intermediate certificates
- example.com.crt # Certificate
- example.com.p7b # only contains certificates and chain certificates
I need to configure NGINX to accept HTTPS, but I feel a bit confused as I do not have the most experience with SSL, and most examples seem to use a certificate/key pair. Would this NGINX configuration be the correct approach?
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /path/to/example.com.crt;
ssl_certificate_key /path/to/example.com.crt;
...
}
Like others pointed out in the comments you need to use the private key for ssl_certificate_key. If it helps further, below is an excerpt from an Nginx configuration using Let's Encrypt SSL certificates. In some cases cert.pem is not enough and chain.pem is also needed for compatibility across more browsers and server types.
# Full chain fullchain.pem is just a concatenation of public key cert.pem and chain.pem. If you are using certbot this will be automatically created.
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
# Like others pointed out in the comments there should be a private key and not the cert file
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
You can use certbot (a tool by Let's Encrypt) to automate the generation of your certificates. Here is a link with Step by Step instructions for automating HTTPS / SSL Certificate setup for your Nginx Hosted Website
I purchased SSL certificate from a certain hoster and I got these 4 files
> SSL Certificate:
> CSR:
> Private Key:
> CA Certificate:
How can I install those files into my VPS server using Nginx? My hoster is not collaborative, and I have to figure out how to install this to my client site. All googling leads me to the normal installation where we generate CSR from my VPS, submit to hoster, get certificates, merge and then fix them with Nginx, but for this case, I'm totally confused
Any help, I will appreciate
Typically if you receive your server certificate and private key you would place those in a directory on your web server then target those files inside of your config file. This can be a full path or a path relative to the .conf file where this server is configured.
Configure HTTPS server
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /path/to/your/file.crt;
ssl_certificate_key /path/to/your/file.key;
}
Depending on your certificate provider they should have also given you a file that contains the CA chains necessary for browsers to validate your certificate. I'm guessing the file you call CA Certificate is that file. You will need to combine both your server certificate and the CA certificate, then target that file inside of your nginx conifiguration.
Example:
cat SSL_Certificate CA_Certificate > website.crt
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /path/to/your/website.crt;
ssl_certificate_key /path/to/your/website.key;
}
I'm totally new to NGINX. I would like to use the free version (not nginx plus) to load balance (reverse proxy) between 3 servers and the connection must be SSL / 443.
Do i put the SSL certificate on the NGINX load balancer server or do I put 3 x SSL certs on the 3 web servers individually? I've heard mixed reviews. I'm looking for best performance.
Additional info: i'm using a wildcard SSL cert and the web other web servers are IIS with IP_Hash to keep sessions on the same web servers.
Open your configuration file again for edit.
sudo nano /etc/nginx/conf.d/load-balancer.conf
Then add the following server segment to the end of the file.
server {
listen 443 ssl;
server_name domain_name;
ssl_certificate /etc/letsencrypt/live/domain_name/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/domain_name/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
location / {
proxy_pass http://backend;
}
}
Then save the file, exit the editor and restart nginx again.
sudo systemctl restart nginx
With the HTTPS-enabled you also have the option to enforce encryption to all connections to your load balancer
server {
listen 80;
server_name domain_name;
return 301 https://$server_name$request_uri;
#location / {
# proxy_pass http://backend;
#}
}
Save the file again after you have made the changes. Then restart nginx.
sudo systemctl restart nginx
This question was asked already in the StackExchange network, but I'm going to try and answer your question anyway.
The performance impact should be noticeable, but it really depends on what you're running.
One thing to consider using multiple certificates, is that once the request hits the load balancer, it stays secure inside the datacenter/network.
This is useful, in cases where you don't own the hardware and don't have physical access to the machines/datacenter. This is because there are probably multiple people running servers and applications in a shared space and you can't know for sure if someone in that network is snooping around and watching the traffic. You just can't be sure that's not going to happen.
Using only one certificate (for the load balancer) is called 'SSL Offloading' and you can and should find out more about it here:
https://security.stackexchange.com/questions/30403/should-ssl-be-terminated-at-a-load-balancer
https://security.stackexchange.com/questions/79672/in-detail-how-does-ssl-offloading-acceleration-termination-work
SSL performance implications
https://serverfault.com/questions/112547/does-using-ssl-cause-a-significant-performance-hit
I'm using nginx(1.1.9) for serving debian packages on https by using client certificate feature.
listen 443 ssl;
...
ssl_certificate /etc/ssl/ca.chain.crt;
ssl_certificate_key /etc/ssl/server.key;
#ssl_crl /etc/ssl/ca-crl.pem;
ssl_client_certificate /etc/ssl/ca.pem;
ssl_verify_client on;
ssl_verify_depth 2;
ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1;
...
error_log /var/log/nginx/error.log debug;
...
I use reprepro to config an apt repo.I can use apt-get update to this repo without any error but when I comment out ssl_crl in order to use revocation list, Log display:
client SSL certificate verify error: (3:unable to get certificate CRL) while reading client request headers, client: xxx.xxx.xxx.xxx, server: apt.myrepo.com, request: "GET /ubuntu/dists/precise/non-free/i18n/Translation-en HTTP/1.1", host: "apt.myrepo.com"
I'm not sure why nginx can find my certificate revocation list.
This occurs because nginx needs to have CRLs for every certificate that's mentioned in ssl_client_certificate cert chain, including the root CA's CRL.
I hit this myself when I created root and intermediate CAs in order to generate certs for intranet sites. When I configured nginx to use SSL client authentication, I only used the CRL from our intermediate CA. nginx needs to see the CRL for every certificate in the chain, including the intermediate CA, to make sure that the intermediate CA's certificate hasn't been revoked by the root. Concatenating the root CRL onto the intermediate CRL fixed the issue.
Notes
The default CRL expiration period (default_crl_days) is 30 days, so you'll need to work out a system for keeping everything up to date.
Thank you to this post, which I found after much Google-fu, that suggested I was missing another cert in the chain.