So i want to setup a payment server with hibiscus (https://www.willuhn.de/products/hibiscus-server/)
and make the connection encrypted with a trusted certificate.
Hibiscus is basically a java servlet which creates a own self
signed ssl certificate, which acording to the author can not be
replaced with another ssl certificate because the private key is
used to encrypt other things.
So my idea is: Setup nginx with a proxy from port 443 to hibiscuses port
8080, tell nginx to trust the certificate of hibiscus and encrypt
nginx's 443 with a letsencrypt cert.
nginx would need to unpack the secure content form hibiscus and then
repack it as its own content right?
Does anyone now if this is possible and how?
All help is much appreciated
It's not secure. Self signed certificate is not trusted by all of the browsers since the certificate is not signed by any trusted CA, which means, user may suffer from a man-in-the-middle attack. Consider what will happen if I also make a payment server and publish my self signed certificate? User agent can not distinguish which one is real at all.
Related
I'm using Lets Encrypt Certbot to generate ssl certificate btw if you notice my url already have https, I only generated it manually and that's not secured. Just want to know if my url is acceptable to have a ssl certificate.
You can get an SSL certificate for any website. You just have to verify ownership of your domain and once the certificate has been issued to you upload it to your website host.
I have multiple Intel NUCs out in the field that I use for displaying digital signage. Out of the thousands I have in the field, a couple complain with this error:
SSL certificate problem: self signed certificate in certificate chain. More details here: http://curl.haxx.se/docs/sslcerts.html, curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
I've confirmed that the cert is not expired, and the domain name matches
These units are running on Debian 7
Could the network they are on cause this issue with some sort of firewall setting?
When you visit the website what certificate is shown in the web browser? In your curl bundle is that the same certificate which is supposed to be used for SSL encryption? I'd guess no. CA will sign your cert.pem so that web browsers will show your green lock thereby authenticating your website. You most likely have an issue on the back end with the configuration of your curl bundle. You need to make sure that your server is using the CA cert not a self signed certificate like ssl-cert-snakeoil.pem for example.
Essentially your website should be using a static IPv4 address. As far as a network firewall stopping an SSL handshake from happening that may be possible, I have seen it happen on specific ports for example port 22 for ssh connections may be blocked at the network gateway for inbound traffic on a client side computer attempting a connection to a server. The SYN/ACK https://tools.ietf.org/rfc/rfc793.txt TCP handshake may time out in that type of network fire wall situation. However since you are getting an explicit response from your server about a self signed cert a firewall issue does not seem to be the problem.
In cloudflares cryptography settings I have set SSL to Full (Strict) and the Universal SSL Status is on Active Certificate as you can see:
But the thing is I am using also a certificate on my server by letsencrypt/certbot, which also works If I deactivate cloudflare, so I wonder if there is now some kind of double encryption?
nginx(ssl) --> cloudflare(ssl) --> enduser
There is no double encryption in the form of two encryptions inside each other. Instead there is one encryption between browser and Cloudflare and another one between Cloudflare and nginx. Both Cloudflare and nginx have access to the plain (unencrypted) data. The browser will only see and validate the certificate from Cloudflare while Cloudflare will see and validate the certificate from LetsEncrypt (served from nginx).
To begin let's say I have this configuration :
mywebsite.com is related on machine 0.0.0.1 (with ssl certificate)
cloud.mywebsite.com is related on machine 0.0.0.2 (without ssl certificate)
can I ask for a new SSL certificate for "cloud.mywebsite.com" or this will create issues because of domain/subdomain ?
Thanks for the response.
Instead of asking for a new SSL Certificate, you only need to get Wildcard SSL Certificate that will secure your main domain as well as its all sub-domains. For example:
If you get Wildcard SSL certificate for *mywebsite.com then it will secure,
https://cloud.mywebite.com
https://mail.mywebsite.com
https://photos.mywebsite.com
https://anything.mywebsite.com
So, you will not have to manage multiple SSL certificates for your main domain and its sub-domain. Wildcard SSL certificate will reduce the hassle of server administrators for multiple SSL management. I suggest you to read this article, which will give you clear understanding of Wildcard SSL Certificate.
I use a gitblit server.
I can access it using: https://localhost:8443, but when accessing https://192.168.10.1:8443, which is the IP address of my PC, I see SSL Error.
Can someone please shed a light on what I might be doing wrong?
Certificates are tied to hostnames.
By default Gitblit GO generates a self-signed certificate for localhost. If you access Gitblit GO over https using a different hostname (like the IP address) the browser will complain about the hostname mismatch. It will also complain about the self-signed certificate even if you are accessing the server from the expected hostname. Both of these are standard security responses.
Your solution choices are:
Add an exception for your self-signed cert
Initiate a CSR (certificate signing request) and purchase a signed certificate through a Certificate Authority (Thawte, VeriSign, etc).
Don't use https