I used godaddy ssl certificate to setup secure my angular 6 application. I hosted that in nginx server and setup ssl certificate. after setup my browser shows certificate(invalid) and Your connection to this site is not secure. so i have to proceed it unsafe option.
I used following configuration to setup ssl in nginx and admin.****.com is my sub domain used for host the site.
server {
listen 443;
listen [::]:443;
ssl on;
ssl_certificate /etc/ssl/certs/****.com.1.2019.chain.crt;
ssl_certificate_key /etc/ssl/private/***.com.1.key;
root /var/www/frontend;
index index.html index.htm index.nginx-debian.html;
server_name admin.***.com www.admin.*****.com;
location / {
try_files $uri $uri/ /index.html;
}
}
I have installed ssl certificate using letsencrypt in my nginx server. It works perfectly in the following domain:
http://shajao.com
Site gets redirected perfectly and ssl is working nicely with an A+ score in ssllabs.
I followed this instruction:
https://medium.com/#jnwarp/lets-encrypt-configure-nginx-with-a-perfect-score-on-ssl-labs-6fc10d2e4bf7
I tried to do the same thing on same server but different domain name but can't get it to work.
Basically ssl is not working. So when I hit the domain in browser it starts an infinite redirection loop. So I stopped the http to https redirect and found that https is not working which gets the site redirected to http.
My dns is managed using cloudflare and I tried turning off the ssl feature from there as well.
My server code:
server {
listen 80;
listen [::]:80;
server_name getcoursetube.com www.getcoursetube.com;
root /media/6sense/www/getcoursetube.com;
index index.html index.htm index.nginx-debian.html;
# return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
root /media/6sense/www/getcoursetube.com;
index index.html index.htm index.nginx-debian.html;
server_name getcoursetube.com www.getcoursetube.com;
location / {
try_files $uri$args $uri$args/ /index.html;
}
error_log /media/6sense/www/getcoursetube.com/logs/error.log;
access_log /media/6sense/www/getcoursetube.com/logs/access.log;
#WARNING: Please read before adding the lines below!
add_header Strict-Transport-Security "max-age=31536000;
includeSubDomains" always;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl_certificate /etc/letsencrypt/live/getcoursetube.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/getcoursetube.com/privkey.pem;
ssl_trusted_certificate /etc/nginx/ssl/chain.pem;
}
After spending hours, I tested my certificate on DigiCert. And found that DigiCert is showing a SSL certificate that is issued by Cloudflare.
I turned off SSL from Cloudflare but it didn't work. So I had to quit Cloudflare.
I removed my site from Cloudflare and managed my DNS through GoDaddy (from where I purchased my domain). And it worked perfectly.
Let me know if anybody has a better answer and made it work through Cloudflare as well.
Update:
I readded my domain on Cloudflare and set SSL to full mode in Cloudflare. Removed the redirection code from Nginx server configuration and enabled always https on Cloudflare. And everything started working perfectly
the reason for me was i didnt allow inbound traffic to the port 443 on my instance.
Is it possible to create my own SSL Certificate that is trusted in browsers? so if a user enter my website they dont need to trust my website. Just like be professional websites?
i'm using nginx.
You can't create one because you are not a certification authority trusted by browsers.
What you can do though is getting a free one from Let'sEncrypt. You have to renew it every 90 days but you can make this on a cronjob quite easily
If you want to create your own certificate authority, I can't help you. But if you just want a free SSL Certificate, that is pretty easy: You can use Letsencrypt.
For example if you have SSH Access to your server, you can use Certbot.
Then just download it for your distribution and type:
./certbot-auto certonly --webroot -w /var/www/your_web_root -d yourdomain.com
Then all you need to do is changing your nginx site config so it supports SSL.
You can look at my example on github:
https://github.com/NLDev/dotfiles/blob/master/nginx.conf
This config scores an A+ on the SSL-Labs test.
Or you can use this stripped down version:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name example.com;
return 301 https://example.com$request_uri;
location ~ /.well-known {
allow all;
}
}
server {
listen 443 ssl default_server;
root /var/www/example.com/public_html;
index index.html index.htm index.php;
server_name example.com;
ssl on;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location /.well-known/acme-challenge {
root /var/www/letsencrypt;
}
location ~ /.well-known {
allow all;
}
}
Replace example.com with your domain and change
/var/www/example.com/public_html;
to your webroot.
You can create your own self-signed certificate, but it is not trusted by browsers due to absence of root certificate in the browser list. Browsers will only trust on preinstalled trusted root certificate which are issued by third-party certificate authorities.
Each browser uses a different set of certificate authority (CA) certificates. You can check the trusted root certificates for the major browsers.
Firefox: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/
Chrome: http://www.chromium.org/Home/chromium-security/root-ca-policy
Opera: https://certs.opera.com/
iOs: https://support.apple.com/kb/ht5012
You should get an SSL certificate from trusted certificate authority that recognized by browsers. To install an SSL on your nginx server, you can follow this quick guideline - https://www.ssl2buy.com/wiki/how-to-install-ssl-certificate-on-nginx-server
SO...
I have a node application running on a server on port 8080 and I am trying to enabled it to work over SSL using NGINX and CloudFlare. Note the following...
My host is running Ubuntu 16.04 LTS
I am currently using CloudFlare's Universal SSL (free tier)
I have my test host DNS setup as test.company.com
I have copied the CloudFlare origin pull cert from this post to my test box's /etc/nginx/certs
...my previous NGINX configuration looked like...
server {
listen 80;
location / {
proxy_pass http://localhost:8080;
}
}
...it now looks like...
# HTTP
server {
listen 80;
listen [::]:80 default_server ipv6only=on;
return 301 https://$host$request_uri;
}
# HTTPS
server {
listen 443;
server_name test.company.com;
ssl on;
ssl_client_certificate /etc/nginx/certs/cloudflare.crt;
ssl_verify_client on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers on;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://localhost:8080/;
proxy_ssl_session_reuse off;
proxy_set_header Host $http_host;
proxy_cache_bypass $http_upgrade;
proxy_redirect off;
}
}
...I followed the example here and the link it provides here and I'm skeptical that everything above is required (I'm a minimalist). Whenever I run sudo nginx -t I still get errors around ssl_certificate and ssl_certificate_key not being specified. I cannot figure out how to download the require files from CloudFlare and from what I understand, I don't believe I should need to.
If I try to re-use the CloudFlare origin pull cert as both the ssl_certificate and ssl_certificate_key, I get the error nginx: [emerg] SSL_CTX_use_PrivateKey_file("/etc/nginx/certs/cloudflare.crt") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: ANY PRIVATE KEY error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib)
I am confident that it is possible to create my own self-signed certificate, but I am planning on using this strategy eventually to spin up production machines. Any help on pointing me in the right direction is much appreciated.
It looks like you're using Cloudflare's Origin CA service, nice!
The issue looks like you've put your SSL private key in the ssl_client_certificate attribute and not put your real SSL certificate in your configuration. Your Nginx SSL configuration should contain the following lines instead:
ssl_certificate /path/to/your_certificate.pem;
ssl_certificate_key /path/to/your_key.key;
Make sure SSL Certificate corresponds to the .PEM file with the correct contents, and the Certificate Key file contains the .KEY file with the correct contents too.
To generate a certificate with Origin CA, navigate to the Crypto section of the Cloudflare dashboard. From there, click the Create Certificate button in the Origin Certificates section. Once you complete the steps in the wizard, you will see a window which allows you to download both the certificate file and the key file. Make sure you put them in the correct files and install them on your web server.
Further reading:
How to install an Origin CA certificate in NGINX
Creating and managing certificates with Origin CA
Also, ssl on is deprecated, instead, use listen 443 ssl;.
I am new to CURL world, coming from Windows + .NET domain.
Trying to access Rest API for basic authentication at http://www.evercam.io/docs/api/v1/authentication.
curl -X GET https://api.evercam.io/v1/... \
-u {username}
Don't know how to use this command on windows command prompt after having CURL setup successfully. Tested CURL as follows:
C:\>curl --version
curl 7.33.0 (x86_64-pc-win32) libcurl/7.33.0 OpenSSL/0.9.8y zlib/1.2.8 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp s
ftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate Largefile NTLM SSL SSPI libz
Now i am ending with this
C:\>curl -u myuser:mypassword -X GET https://api.evercam.io/v1/
curl: (51) SSL: no alternative certificate subject name matches target host name 'api.evercam.io'
How can I fix this SSL issue 51 error ?
It usually happens when the certificate does not match with the host name.
The solution would be to contact the host and ask it to fix its certificate.
Otherwise you can turn off cURL's verification of the certificate, use the -k (or --insecure) option.
Please note that as the option said, it is insecure. You shouldn't use this option because it allows man-in-the-middle attacks and defeats the purpose of HTTPS.
More can be found in here: http://curl.haxx.se/docs/sslcerts.html
Editor's note: this is a very dangerous approach, if you are using a version of PHP old enough to use it. It opens your code to man-in-the-middle attacks and removes one of the primary purposes of an encrypted connection. The ability to do this has been removed from modern versions of PHP because it is so dangerous. The only reason this has been upvoted 70 time is because people are lazy. DO NOT DO THIS.
I know it's a (very) old question and it's about command line, but when I searched Google for "SSL: no alternative certificate subject name matches target host name", this was the first hit.
It took me a good while to figure out the answer so hope this saves someone a lot of time!
In PHP add this to your cUrl setopts:
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, FALSE);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, FALSE);
p.s: this should be a temporary solution. Since this is a certificate error, best thing is to have the certificate fixed ofcourse!
The common name in the certicate for api.evercam.io is for *.herokuapp.com and there are no alternative subject names in the certificate. This means, that the certificate for api.evercam.io does not match the hostname and therefore the certificate verification fails.
Same as true for www.evercam.io, e.g. try https://www.evercam.io with a browser and you get the error message, that the name in the certificate does not match the hostname.
So it is a problem which needs to be fixed by evercam.io. If you don't care about security, man-in-the-middle attacks etc you might disable verification of the certificate (curl --insecure), but then you should ask yourself why you use https instead of http at all.
it might save some time to somebody.
If you use GuzzleHttp and you face with this error message cURL error 60: SSL: no alternative certificate subject name matches target host name and you are fine with the 'insecure' solution (not recommended on production) then you have to add
\GuzzleHttp\RequestOptions::VERIFY => false to the client configuration:
$this->client = new \GuzzleHttp\Client([
'base_uri' => 'someAccessPoint',
\GuzzleHttp\RequestOptions::HEADERS => [
'User-Agent' => 'some-special-agent',
],
'defaults' => [
\GuzzleHttp\RequestOptions::CONNECT_TIMEOUT => 5,
\GuzzleHttp\RequestOptions::ALLOW_REDIRECTS => true,
],
\GuzzleHttp\RequestOptions::VERIFY => false,
]);
which sets CURLOPT_SSL_VERIFYHOST to 0 and CURLOPT_SSL_VERIFYPEER to false in the CurlFactory::applyHandlerOptions() method
$conf[CURLOPT_SSL_VERIFYHOST] = 0;
$conf[CURLOPT_SSL_VERIFYPEER] = false;
From the GuzzleHttp documentation
verify
Describes the SSL certificate verification behavior of a request.
Set to true to enable SSL certificate verification and use the default CA bundle > provided by operating system.
Set to false to disable certificate verification (this is insecure!).
Set to a string to provide the path to a CA bundle to enable verification using a custom certificate.
I had the same issue. In my case I was using digitalocean and nginx.
I have first setup a domain example.app and a subdomain dev.exemple.app in digitalocean.
Second,I purchased two ssl certificat from godaddy.
And finaly, I configured two domain in nginx to use those two ssl certificat with the following snipet
My example.app domain config
server {
listen 7000 default_server;
listen [::]:7000 default_server;
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
root /srv/nodejs/echantillonnage1;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name echantillonnage.app;
ssl_certificate /srv/nodejs/certificatSsl/widcardcertificate/echantillonnage.app.chained.crt;
ssl_certificate_key /srv/nodejs/certificatSsl/widcardcertificate/echantillonnage.app.key;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
proxy_pass http://127.0.0.1:8090;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
#try_files $uri $uri/ =404;
}
}
My dev.example.app
server {
listen 7000 default_server;
listen [::]:7000 default_server;
listen 444 ssl default_server;
listen [::]:444 ssl default_server;
root /srv/nodejs/echantillonnage1;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name dev.echantillonnage.app;
ssl_certificate /srv/nodejs/certificatSsl/dev/dev.echantillonnage.app.chained.crt;
ssl_certificate_key /srv/nodejs/certificatSsl/dev/dev.echantillonnage.app.key;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
proxy_pass http://127.0.0.1:8091;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
#try_files $uri $uri/ =404;
}
}
When I was launching https://dev.echantillonnage.app , I was getting
Fix CURL (51) SSL error: no alternative certificate subject name matches
My mistake was the two lines bellow
listen 444 ssl default_server;
listen [::]:444 ssl default_server;
I had to change this to:
listen 443 ssl;
listen [::]:443 ssl;
As the error code says, "no alternative certificate subject name matches target host name" - so there is an issue with the SSL certificate.
The certificate should include SAN, and only SAN will be used. Some browsers ignore the deprecated Common Name.
RFC 2818 clearly states
"If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead."