To begin with, I already posted the same question in serverfault.com and received no help, so I'm repeating it here out of desperation.
Recently PayPal is requiring servers to support SHA-256. Here's an article referring to this issue:
https://www.paypal-knowledge.com/infocenter/index?page=content&id=FAQ1766&expand=true&locale=en_US
At the top of the article, it states,
Update your integration to support certificates using the SHA-256 algorithm. PayPal is upgrading SSL certificates on all Live and Sandbox endpoints from SHA-1 to the stronger and more robust SHA-256 algorithm.
We have a dedicated CentOS server with numerous sites, mostly WordPress. Quite a few use PayPal IPN but do not have dedicated IPs or SSL Certificates. What needs to be changed to the server so these sites will support SHA-256? Our server is situated with Limestone Networks so I've created a ticket and asked repeatedly for assistance to no avail. They keep repeating SSL's need to be updated on the server. Would that be a wildcase SSL certificate in the usage case I described? Any assistance would be greatly appreciated.
Based on your comments, it sounds like this is nothing to do with SHA256, but a simple CN mismatch. A certificate is only good for the names listed in it. You could try adding a subjectAltName for each of the required hosts, or a wildcard certificate for *.example.com (though I wouldn't trust one of those for my server.)
Related
Friendly Disclaimer: I am new to working with Keycloak and IdP in general. So it's likely that I use incorrect terminology and/or am more confused than I think I am. Corrections are gratefully accepted.
My question is conceptual.
I have a TLS certificate that is terminated on my host machine by my host company. My reverse proxy (Traefik) is picking up that certificate.
Which of the following proxy modes should I use now to be able to deploy Keycloak to production: edge, reencrypt or passthrough? (see here for relevant documentation)
I can pretty much rule out passthrough, because as I wrote, the TLS certificate is terminated on the server. But I am unsure if I have to bring my own certificate and reencrypt or if it is considered safe to go along with edge?
I have done my best to keep this question short and general. However, I am happy to share configurations or further details if needed.
As far as I know, most organizations consider a request to be safe when the proxy validated and terminated the TLS. It also removes the performance overhead (depends on your load). Unless your organization is going for Zero Trust for its internal network, using the edge should be totally acceptable.
I work for advertising seo company. They have dedicated server and want also use SSL for the clients. They asked me to find the best option regarding that, I need help from you guys. I suppose some of you are more experienced in this.
Should they buy certificates separately for each client?
Create self signed certificate (Is there any way avoid security warnings).
Use wild card or multiple domain SSL
Other option (please suggest)
Thanks
I would recommand using LetsEncrypt.
It is free, you can do wildcard, automatic renewal every 3 month, documentation, etc.
I'm a big fan of it.
You can also use your registrar, sometimes they also sell certificates for the domain they sell. Like Gandi for example, you got 1 year free certificate with a domain, and they guide you all along on how to install it.
I have a digitalocean One-Click Ubuntu Wordpress Droplet with a NameCheap domain.
I've never done anything with SSL before so I followed a tutorial (https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-ubuntu-14-04). Once I made it to the end with no issues, I realized that it was a self-signed certificate and didn't remove the warning that browsers were giving and that I had to purchase one from a provider. Since my domain is through NameCheap, I went through them (Comodo?) and followed their linked tutorial for the setup (https://brettdewoody.com/how-to-setup-ssl-certs-with-digitalocean-and-comodo/).
I made it through that and browsers were bringing up an error saying that it was a self-signed certificate and it could be a problem. I went back through both tutorials and checked my stuff and tried to remove what I could of the original part. After blindly finagling things for a few hours, my site receives an A+ from this ssl checker (https://www.ssllabs.com/ssltest/analyze.html?d=vc2online.com) but browsers refuse to connect to the site (vc2online.com).
I don't even know where I need to start to get this to working properly.
Currently your issue is that you have 301 redirect from vc2online.com to www.vc2online.com but unfortunately your ssl certificate is only for vc2online.com, not www.vc2online.com.
You enabled HSTS so going backward won't be easy.
The quickest way to solve it is by using let's encrypt instead the comodo certificate.
You can use certbot to fully automate the process. You will find out it is much easier (and cheaper) than comodo paid certificate
P.S. I think this question should be asked in super user / server fault.
I need to set up https communication between a Tomcat application server and a back end system. The web server hosts a public website, so is in a DMZ.
My question is if there any advantage in using official CA certificates, over using self signed certificates in this situation (machine to machine communication)?
I keep hearing self signed certificates should not be used on production systems, but I'm not sure I understand why (for machine to machine communication).
The risk lies in how effective the defenses protecting the hosts in question are, including the network connection between them. Given that weaknesses and exploits are being found all the time, it is reasonable to say there could be issues with self-signed certificates used in a production environment - which includes hosts in a DMZ.
Here's the reason: man-in-the-middle. In short, if either host - or the network between them - becomes compromised, then the traffic between them will still be encrypted, but because the certificate is self-signed, a man-in-the-middle (aka "MITM") would be able to introduce a transparent proxy using a self-signed cert, which will be trusted by both sides.
If instead your hosts use a public CA, then the MITM approach cannot work.
If the annual $15-50 investment per host is more costly than the information on and between them - including what could be on them (e.g., compromised, serving malware), then the choice is simple: don't worry about buying certs. Otherwise, it's important to look into them.
The comment by Adam Hupp on this webpage provides a good, simple scenario:
http://www.vedetta.com/self-signed-ssl-certificates-vs-commercial-ssl-certificates-how-mozilla-is-killing-self-signed-certificates
And here's a more fleshed out description of the risk:
http://blog.ivanristic.com/2008/07/vast-numbers-of.html
And finally a balanced look at the two scenarios, though this article only considers self-signed OK when there is a fully-functional, properly protected and implemented Certificate Authority server installed:
http://www.networkworld.com/news/tech/2012/021512-ssl-certificates-256189.html
I see no advantage in using official certificates for this task - besides the fact that your marketing dept. could claim your infrastructure is "100% certified by $CA". Encryption algorithm/strength and cert duration can be the same, depending on how you configure it.
The recommendations you hear probably focus on the far more common usage of HTTPS for communication with browsers, which nowadays complain about self signed certs. For data transfer between servers, I think it's good practice to encrypt traffic the way you plan on doing it!
I'm not quite sure if this question applies to this forum but if it does maybe someone knows if it is possible using Open SSL to create a SSL sertificate that browsers wouldn't throw warning messadges that our created SSL sertificate is untrusted?
Technically it is possible if you have CA's private key to sign the newly created certificate. As you probably don't have a key, the answer is probably no. Just go ahead and purchase a certificate from one of CAs. If you do minimal research, you will find that some CAs offer very affordable prices.
This is probably better handled on server fault, but I will tell you that NO you cannot do this. The reason browsers don't like your certificate is that you are not a recognized certificate authority. As such, a browser will always warn about your certificate being untrustworthy, since the browser does not know who you are, or why anyone should trust you.
EDIT: As Alex K points out, you can install your certificate on machines you know will access your site, which works reasonably well for scenarios where the site will only be accessed by a limited number of known users/machines. My point still stands regarding wider distribution. Thanks, Alex.