Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Greeting,
I have installation of AspDotNetStoreFront on Amazon (Server 2012 and IIS8).
That cart need to be connected to StoneEdge software. We purchased a script (for our cart) from StoneEdge. So far we have been unable to connect.
StoneEdge support told me that I need to have a SSL Certificate in place. But I cant have it, since the site is still in test phase. I have seen on MSDN that I cant set SSL until I have valid SSL Certificate.
Is there a way to set up generic/dummy certificate so we can test it?
In my opinion I do not think SSL is required for testing purposes... or I am wrong?
Whether or not a SSL certificate is required to connect with StoneEdge, really depends on their integration requirements. In other words, yes it may be valid that a SSL certificate is required.
A SSL certificate can certainly be created/acquired for testing purposes. However, you will have to determine what type of certificate will support your testing needs.
For example, when appropriate I may use a self-signed certificate. In other instances, I may need a certificate signed by a trusted CA. It may also be useful to note that some providers, like Comodo, offer free trial SSL certificates.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I'm currently building an application and I want to make sure that I use HTTPS throughout the whole application. The application is a web application in Golang and I wanted to know how to get legit certificates so that my application can be secure.
I would say it depends on how the application is gonna be deployed.
Hosting the application on a VPS / private server as a systemd service ?
You could look into Certbot if you want to manage SSL renewal automatically. But still you'll need to provide the certificate into your application, or use a HTTP proxy such as NGINX to expose your application on HTTPS.
This approach would work, but can be painful as you'll need to install / manage Certbot & possibly Nginx on your server.
Another good option would be to use Traefik, it's a Proxy server with builtin Let's Encrypt support, so that you'll be able to use free SSL, automatically renewed, by just installing the service, and creating a little configuration file.
I would personally choose the external proxy approach on this one, and especially Traefik. It shouldn't be the job of you web application to manage HTTPS, but more an external proxy. So that if one day you need to scale your application, it shouldn't be painful.
Well, you have a few options. I found it easy to use ZeroSSL to get a trusted certificate, but there are many other ways to do so. You can also use Certbot, but it several dependencies to be installed.
If you are getting certificate for FQDN , you can use Letusencrypt which provides many clients support including certbot. You can find it here
https://letsencrypt.org/docs/client-options/ but please remember it wont work without fqdn.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I'm trying to devise a method to protect my HAProxy SSL certificates while at rest on disk so that if the load-balancer host gets hacked, the SSL certificates will not be sitting there ripe for the attacker to pluck.
I realize that at the very least, the certificates must be available in memory in order to be used by HAProxy to negotiate SSL connections. However, I’d like to do whatever is possible to keep the certificates secure.
How can I setup the ssl-cert directory to be protected and/or encrypted and be available to HAProxy only when it needs the information (presumably when the service is started)?
Currently I see two ways this could be achieved.
Use some sort of linux/*nix filesystem-level encryption.
This means munging the HAProxy init/upstart script to require a specific password or key file to exist on disk. This password is then used to extract the certs from an encrypted archive file (e.g. RAR or something?) into the HAProxy /etc/haproxy/certs directory. After the HAproxy service has started use srm the password/key file along with the /etc/haproxy/certs directory.
Create an external API service management layer which runs on a different (super secured) host. This service will store the certificates and orchestrate load-balancer service restarts and reloads. This service would rsync over the haproxy certs directory, restart or reload it via ssh, and then ssh … srm the certs directory to securely erase the /etc/haproxy/certs directory.
I’d appreciate feedback on these ideas, any relevant experience, or any other way this security goal can be achieved.
Additional resources:
Here is a relevant related question on SO regarding multi-ssl HAproxy.
HAProxy SSL termination documentation
Although this isn't the right forum for your question, here's an answer:
Simply protect your SSL certificates with a passphrase.
Upon starting HAProxy, your SSL Library will ask for the passphrase.
Keep in mind that you will need to type the passphrase every time you start/restart HAProxy.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
When adding a new domain to the existing SSL SAN Certificate, how would it affect sites that were using the previous SAN Certificate?
My logical sense is telling me that it will be be able to serve https requests or throw a security warning indicating the certificate being invalid.
As long as a certificate isn't revoked (or doesn't expire), it will be valid for all the SAN names for which it was issued. If another certificate is issued for a set of hosts that overlaps the ones used in a previous certificates, both will be valid for their respective hosts.
Whether a CA chooses to invalidate a previous certificate it has issued within the same account for a similar set of hosts depends on its own policy, but in principle, you could easily get another certificate for the same hosts from a different CA anyway.
This being said, it seems that you're using a single certificate (and a the same private key) across multiple machines, for hosts that don't seem related (at least in the sense that they are served by distinct machines anyway). This is normally considered bad practice, since if one of those machine was compromised, you would have to change the certificate on all the machines.
FYI, as advised by Digicert that adding domains to the existing certificate will not revoke the certificate and should allow the existing one to continue to function as it was before.
HTTPS:// is not support for all the SAN names you remove from certificate and it cause SSL security error or warning for the removed domain names.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
When asked to look into having authentication for my company's website, I ended up using htaccess and htpasswd. Now I'm being asked to look for a more secure solution. One scenario I was advised to look out for was sniffing. I looked around and found HTTPS seems to be the solution I'm looking for.
If the authentication is only going to be accessed by our employees and will allow them access to a database. The activity on this database should be very light. I'm under the impression no more than say... 5 queries per session, and the data retrieved would be lightweight too.
From what I've read, seems like HTTPS is what I should be betting on here. My knowledge in authentication and encryption is next to nil, so I'm wondering if there are any other options to go about secure authentication for our site.
HTTPS primarily provides:
confidentiality
integrity
authentication of the server to the client
The latter is an important measure against man-in-the-middle and impersonation attacks. Think of somebody pretending to be the server and fooling the client in submitting sensitive data like passwords.
Note that - in order to work - the server must have an SSL certificate signed by a CA recognized by the client browser. That can either be an SSL certificate obtained by a commerical CA like Verisign or a custom SSL certificate all your users must import into the certificate storage.
Bottom line, HTTPS protects you from spoofing attacks, but only if the certificates are set up correctly. Still, be sure to disable plain HTTP, otherwise an attacker may try a downgrade attack.
With HTTPS in place, you can use any of several method to authenticate the client to the server, including whatever you are using now (I guess HTTP Basic or Digest). Other options include Kerberos, the old NTLM, RADIUS, or client-side SSL certificates.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'll be using a shared Internet connexion starting this September at my school and I was wondering about what someone sniffing traffic with Wireshark may find there. I am not planing to do this myself but I feel I ought to know more about it if I want to sometimes work on my website during class.
Basically, isn't every non-SSL website that asks you for a password and an e-mail totally unsecure to log on on a shared connexion? When you know how many people use the same password for all their web/laptop/mobile accounts, it doesn't take long to get access to someone's all private data if you manage to sniff one password and e-mail.
As for me, I am already looking at how to secure my FTP connexions, but what about my users who log through HTTP? Unless I buy a SSL certificate (which I don't want, the site's too small), they are going to get more exposed to Wireshark sniffers all over the world, right? Isn't this where login tools such as OpenID become handy for small communities, since they do provide a free encryption of passwords?
OpenID and SSL are completely unrelated. OpenID's purpose is to consolidate and give ownership of a user's identity to the user, while SSL is used to keep a user's traffic with your site secret (encrypted). You can use OpenId to keep track of the user (like Stackoverflow does) and still not use SSL for the content pages.