I'm looking to implement a running express server using https, powering an AngularJS application. Currently I have the majority of the application running just on http, but would like to switch over. This isn't a publicly available application. Am I ok to simply use self-signed certificates to implement this in our production environment? Or should I be going through a trusted certificate authority even for internal use?
Using OpenSSL seems pretty simple to generate the key and pem files... but I feel dumb when it comes to acquiring something through a trusted authority. If it's recommended that I DO in fact use a trusted CA, and not self-signed, could someone point me in the right direction on where to go for this?
The answer is "it depends".
You can certainly use self-signed certs, but you will have to manually make sure that all your endpoints are configured to trust your self-signed certs. This is what a trusted certificate authority is used for. The browser has pre-built trust for certificates issues by various public certificate authorities and, in turn, they agree to follow certain procedures related to issuing their certificates. If you go through that process, then browsers will automatically recognized and trust https connections using your certificates (assuming everything is as expected with the connection). If you don't go through that process, then you have to manually tell each endpoint that is going to access your application to trust your certificates. For closed applications with a small number of controlled endpoints, this is very feasible. For open applications or applications with a wide variety of endpoints (random browsers, phones, etc...), this is difficult.
And, you do not want to "teach" your user base to either ignore security/certificate warnings or to blindly trust things that the browser tells them might be insecure so you want to not leave this to your users - you want to pre-configure the endpoints to trust your new self-signed certs.
To give you an example, there are home security camera systems that have web access. If the only ways you need to do web access are from 2 or 3 different browsers, it's not really a problem to use a self-signed cert and configure those 3 browsers to trust it.
But, if you had some web application that many different people would access, then it wouldn't really be practical to manage the certificate trust on a rotating set of browsers and it would just be a lot less complicated and a lot more likely to be secure to use a trusted CA.
Personally I prefer using CA trusted certificates over self-signed certificates for production environments (or even developer environments) since you need to trust/add exceptions or overwrite programatic SSL checks when you are using self-signed certificates.
If you decide to use CA trusted certificates, I recommend looking into Certbot + Let's Encrypt. It is a trusted CA and supports most of the famous servers. It is also free and really easy to use. The only downside is that you need to renew the certificate every 3 months. This too can be automated depending on your platform/server.
Related
My website runs on Google App Engine and is so far accessed via HTTP. I would like to change that to HTTPS. However, using the appspot.com domain instead of my own domain is not an option for me.
Is there any straightforward way to do so without having to deal with manually managing (updating etc.) certificates?
Now, when you build apps on App Engine, SSL is on by default — you no longer need to worry about it or spend time managing it. We’ve made using HTTPS simple: map a domain to your app, prove ownership, and App Engine automatically provisions an SSL certificate and renews it whenever necessary, at no additional cost. Purchasing and generating certificates, dealing with and securing keys, managing your SSL cipher suites and worrying about renewal dates — those are all a thing of the past.
To get started with App Engine managed SSL certificates, simply head to the Cloud Console and add a new domain. Once the domain is mapped and your DNS records are up to date, you’ll see the SSL certificate appear in the domains list. And that’s it. Managed certificates is now the default behavior — no further steps are required!
https://cloudplatform.googleblog.com/2017/09/introducing-managed-SSL-for-Google-App-Engine.html
No. You have to buy and upload your own certificate. The process is quite straightforward, though.
I need to create licensing server for my application.
Application should ping licensing server and if license expired stop working.
How should it be done securely? I haven't found any articles about this.
More exactly, what confuses me is how to prevent attacker to do the following
Look where I make requests (using fiddler e.g.)
Create his own server
Point his PC to that server using etc/host file.
Any best practices about this?
You can do this by enabling HTTPS on your server. Your application will need to verify the HTTPS certificate to ensure the remote host is not a fake licensing server.
This article describes the attack you mention, and how is it possible to avoid it using HTTPS.
Here's a useful sample :
Defeating Active Attackers
Verifying the server’s authenticity is key to defeating active attackers. Fortunately, TLS has this covered as well. As you recall, HTTPS is really just HTTP running over TLS. When HTTPS is implemented correctly, here is what happens to active attackers.
Because the legitimate server’s Certificate Authority (CA) verifies
ownership of the domain (yourwebsite.com), an active attacker cannot
fake the certificate. Encryption prevents the attacker from reading or
modifying any intercepted data. In short, the entire CIA triad is
satisfied and both passive and active attackers are defeated.
In your case, the roles are slightly different : the user is your application, while the potential attacker is the application user who doesn't want to pay for a license. ;)
We can activate secure connection for backends but as oppose to front-end we get this certificate warning: (is there a solution to no get this warning?)
This is probably not the site that you are looking for!
You attempted to reach backend.xxxx.appspot.com, but instead you actually reached a server identifying itself as *.appspot.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of requestprocessor.qminer-trial.appspot.com.
You cannot proceed because the website operator has requested heightened security for this domain.
Help me understand
When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party trusted by your computer. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website that you intended and not a third party (such as an attacker on your network).
In this case, the address listed in the certificate does not match the address of the website that your browser tried to go to. One possible reason for this is that your communications are being intercepted by an attacker who is presenting a certificate for a different website, which would cause a mismatch. Another possible reason is that the server is set up to return the same certificate for multiple websites, including the one you are attempting to visit, even though that certificate is not valid for all of those websites. Google Chrome can say for sure that you reached *.appspot.com, but cannot verify that that is the same site as requestprocessor.qminer-trial.appspot.com which you intended to reach. If you proceed, Chrome will not check for any further name mismatches.
This is a known issue: http://code.google.com/p/googleappengine/issues/detail?id=7288
It's a limitation of SSL and browser implementations: Wildcard subdomains on appengine over https on firefox
The workaround, as per docs, is to use -dot- in place of dots in your subdomain name: subdomain-dot-domain.appspot.com
This surely works for subdomains (tested), but I'm not sure if it works for backend domains. Please test it and let us know.
Update:
I tested this on one of my test backends (forgot it's still up) and it works as expected with the -dot- workaround.
I've been struggling with this for a few days, and I hope someone can suggest some solutions.
I have a self-hosted WCF service, the main interface to this service will be a Silverlight application that is hosted in a non-IIS, potentially shared, environment.
I'm aware of the TransportWithMessageCredential and a custom authentication validator. The only requirement of this seems to be that the host has HTTPS and a valid SSL certificate. However, there are certain enviroments the product will be operating in where they don't wan't the hassle of paying for and maintaining a certificate, or the shared environment doesn't allow SSL.
The easy answer would be to tell them to find a new host/admin, but I've been asked to see if there are any other fesible authentication mechanisms.
Any suggestions?
Thanks
Without SSL there really isn't any way for you to secure the users credentials "across the wire". You "could" do some encryption in the Silverlight app, but this really amounts to obfuscation vs. "real" security.
The only option that I can think of in this scenario would be moderately secure would be a 3 factor solution such as giving all the users SecureID key fobs.
We had the same problem. We made the installer for the WCF service that creates a self-signed certificate, adds it to the system certificate store and configures the binding with HTTPS port. The Silverlight application had a link to download this certificate from the WCF service. So users could download this certificate and install it in the Trusted Root certificate store.
We are developing an application that needs to talk to some hardware (serial port) on the machine, and most of what we do is WPF and .net, so an xbap seems logical.
My concern is with the certifcates. I have seen a bunch of people showing how to create and self sign applications, but then the user is required to install that to their machine manual to trust the root. I am curious if we purchase an cert from say Verisign if that requirement will then go away?
I have no problem if there is a prompt requesting full trust, but I do not want my remote users dealing with installing certificates.
Thanks
If you purchase a code signing certificate from a trusted authority then the users will not need to do anything with certificates.
If your certificate comes from a trusted authority, the users won't generally need to worry about it (where it becomes an issue is if you let your certificate lapse). If you're a member of Code Project, you can get a "cheap" certificate from one of their partners. More information here.
there is a solution here =D
XBAP full trust deployment
create your own certificate and deploy full trust. 0 cost. if you're looking something like secure layer cert, you may head on http://www.comodo.com/business-security/digital-certificates/ssl-certificates.php?entryURL= for free SSL