I run an nginx-powered application and I recently turned my attention to using it over https. This is the module in nginx that does this: http://wiki.nginx.org/HttpSslModule
However, I'm somewhat unclear about what is actually required to run a site over https.
What else is there to do to serve my site over ssl? What is the role of the certificate, and is it a requirement that I purchase it from somewhere?
You need a certificate to prove to your user that the server they're connected to is indeed the one intended (and not a MITM attacker).
If your server is to be used by a limited number of users to whom you could give a certificate explicitly, you could use a self-signed certificate or create your own certification authority (CA).
Otherwise, if you want your certificate to be recognised by most browsers, you'll need to get one from a commercial CA.
You should find more details in this answer. You may also be interested in this.
Related
I have an online shop and I've just installed a new SSL certificate and it was free. It does seem too good to be true. I'm a very cynical type of person.
I don't know about different types of SSL, but I just need to be able to accept payment data (I'm using a PayPal add-in on Opencart).
I got my certificate from letsencrypt and they don't explain much on there website.
But if you go to my website Gwenllian-retail you will see the certificate. Can I handle financial transactions with that?
If not what type of SSL do I need?
One does not need much money or complicated software to create valid SSL certificates. I could create my own with ease, if I wanted. In fact, I have done. There is no reason to think that LetsEncrypt certificates are somehow of a wrong kind.
The question is whether people will trust those certificates, and that comes back to whether they trust the Certificate Authority (CA) that signed them. If I sign my own certificate and present that to someone as proof of my identity then that other party has no more reason to trust that the data within accurately identify me than if I just told them directly.
LetsEncrypt serves as the CA for SSL certificates it provides. I have never relied on them for a certificate, but according to hosting company DreamHost, LetsEncrypt certificates are trusted by all major browsers. (LetsEncrypt makes the same claim about itself, too.)
Again, all this trust business is mostly about authentication: whether the entity that presents the certificate (your web site) is really the entity that it says it is. It is not about the nature or quality of the encryption with which the session is secured. That comes down to the capabilities of the two endpoints, and is largely independent of the certificate.
Let's Encrypt is a well known service backed up by many big players. So yes, it's OK to use it in on your site. BUT ! SSL certificate is not everything, it's only one of many shields to protect you application.
I'm having a bit of trouble understanding a bit about SSL, namely self-signed vs certified.
First, is my assumption that a self-signed certificate will still prompt the common browser warning message?
Second, data from a https domain doesn't transfer to a http domain, right? So if I had my site at domain.com, and my api at api.domain.com, I would need two certs, and have both of them setup for https?
Last, I noticed there are free SSL certs at sites like StartSSL. This feels fishy, given it can easily cost $100 for a cert at other sites. Am I wrong in being concerned?
Using a self-signed certificate will cause browser warnings. Your assumption is correct.
It depends; some browsers may warn when this occurs. But you absolutely should serve all of your services on HTTPS, so that clients can authenticate your site(s) and so that the connection is private.
It is possible to support multiple domains on a single certificate, via the Subject Alternative Name (SAN, subjectAltName) X.509 certificate extension. You could also use separate certificates.
StartSSL is trusted by all browsers; their certificates will be accepted and there is nothing "fishy" about them. You could use StartSSL's free offering to obtain two certificates - one for each domain.
If you want a single certificate for multiple domains via the SAN extension, you will have to find a product that supports that, and it will probably not be free. The Let's Encrypt initiative is working to
change the landscape in this regard, but they have not yet launched.
I need to implement a SSL certificate for a website, I've got three questions after some research.
1) I believe i need to buy a SSL certificate and ask my host to install it. My question is do you need to alter any code for the website for the certificate?
2) Before I buy the certificate, the website is going to be built for a couple of month at least. I'm just wondering is there a developing SSL certificate I can use for the developing environment?
3) Or do I have to use self assigned certificate? If so are there any good tutorials on how to create a SSL self assigned certificate on a local machine (wamp) and a developing url site?
Thank you very much.
Sam :)
1) No, you do not need to alter any code on your website at all in order to use an installed SSL certificate. It is as simple as prefixing your desired destination link with the HTTPS: protocol specification instead of the typical HTTP: protocol. However, if you want to determine if your site visitor is using an encrypted page before they do something, such as submit a web form with potentially sensitive data, then depending on what you are developing your site in, you will need to detect if the current page request has been sent over HTTP or HTTPS, then if it is an HTTP requested page, you probably want to redirect the page request to the HTTPS version before proceeding.
2) Other than creating your own "self signed" certificate (more on this in #3), no your only option for a publicly valid SSL certificate is to obtain one from a publicly recognized Certificate Authority (CA). Long story short, a certificate of the same key length using the same encryption standard supported by your server and visitor's web browser, is no stronger or weaker regardless of vendor for purposes of encryption. So you can simply shop by price for your SSL certs. I have no affiliation with GoDaddy, but have been using them for years for public SSL certificates.
3) You certainly can create your own self signed certificate. The methods for doing this vary based on your host server and version. The limitation to a self signed certificate, is that if you go to share this with anyone, you get that warning message from your browser that the certificate is not published from a verifiable source. In most current browsers, it looks like a big scary message that something is wrong and they attempt to warn your user away from doing this. However, of course, there is certainly nothing wrong with using a self signed certificate. This is obviously true for your own development uses. Even a self signed certificate of the same key length and encryption method is as cryptographically secure as a commercially provided certificate. If you want to use a self signed certificate, just search for instruction for doing that for your server OS and version for details. Once it is installed, you will get the warning from your browser when you try to browse to a page over HTTPS. Your browser should show you an option to permanently remember and accept your self signed certificate, after which you will no longer see that warning while that certificate remains installed and valid.
I want to use SSL (https) to secure communication. Is it possible to do it without buying a certificate of some sort?
You can use a self-signed certificate (google it) but your users will get a message saying the certificate is not valid. The traffic will still be encrypted, however.
The reason you have to pay a third party for a "valid" SSL certificate is that part of the purpose of an SSL certificate is to verify the authenticity of your server. If any body could issue an SSL cert with any information they wanted, what's to prevent me from setting up an SSL certificate using Walmart.com's contact information and tricking users into thinking my site is a branch of walmart.com?
In short, you can get the encryption part for free, but if you want to avoid browser identity warnings, you'll need to pay for a third party cert.
You can self sign a cert, or get one from cacert.org or a related free signing community. Most browsers will throw up warnings, so you shouldn't do it for production (if you are an ebusiness), but during development, or if you don't care about the warnings, it's a cheap alternative
As others have said, you can simply and easily use self-signed certificates or set up your own certificate authority (CA) and then issue as many certificates as you want. All these certificates are as valid as the "commercial" ones issued by the big CAs, so there is no technical difference between your certificate and the one from, say, verisign.
The reason most browsers and other client applications warn about your certificate is, that they do not know and therefore not trust your CA. Browsers usually come with hundreds of well-known CA certificates everyone automatically trusts (if thats a good thing, well...), so you don't get a warning when visiting amazon.com via HTTPS. In Firefox, you can go to "Preferences" > "Advanced" > "Encryption" > "View Certificates" to see which CAs or individual certificates your browser currently trusts.
In the end, it's a question of whom you and the users of your service trust. If your users know and trust you (say in company network or a small development team), they can add your CAs certificate to the trusted certificates in their browser. From then, every certificate issued by your own CA will generate no warning and will be trusted just like every other certificate.
I'm developing software which will be deployed using clickonce (on the website foo.com), and which will then connect to my server using WCF with an encrypted transport
So I need an SSL certificate which will :
Identify my foo.com website has really being my website
Identify the exe I deploy using clickonce as being genuine
Identify my application server has really being my application server.
I also want my SSL certificate to be signed by an authority known to the public (ie, firefox or windows won't ask the user to install the authority's certificate first !)
What SSL certificate would you buy?
I've browsed the Verisign website, the "Secure Site EV" certificate costs 1150€ a year (the "Pro" version seems useful only for compatibility with older browsers)
It sounds like you're looking for two different types of certificates:
1 - SSL Certificate - for authentication of your website/application server.
2 - Code Signing Certificate - for integrity/authentication of the exe you deliver.
Typically those are two different certificates, with two different certificate profiles. At the very least, you need one certificate with two different key usages or extended key usages.
A few thoughts in no specific order:
Check your targeted browsers, they should each have a set of preconfigured root certificates - those are the most widely recognized public certificate sources. I'd probably check both Firefox and IE. Certificate vendors known to me as big names are - Versign, GeoTrust, RSA, Thawte, Entrust. But there's also GoDaddy and many others. Anything that comes in the delivered browser as a Trusted Root Certificate, will allow you to connect to your users without additional greif.
I suggest Googling for both "code signing certificate" and "SSL certificate".
How you configure your site will determine whether or not your website is validated or your authentication server is validated. If the certificate is stored on the apps server, then your user is getting SSL encryption all the way to the server. But many sites put the SSL certificate a little farther forward - like on a firewall, and then stage a collection of apps servers behind it. I don't see a security flaw in that, so long as the networking is carefully configured. To the outside users, both configurations will look the same - they'll get the lock on their browsers and a certificate that tells them that www.foo.com is offering it's credentials.
I'm seeing pretty great deals for SSL Certificates:
- GoDaddy - $12.99
- Register.com - $14.99
But they aren't necessarily code signing certifiates. For example, while GoDaddy's SSL Cert is $12.99, their code signing certs are $199.99! That's part of many certificate vendors business models - lure you in with cheap SSL Certs, and make you pay for code signing. A case could be made that code signing certificates are relatively higher liability. But also... they have to subsidize the cheap SSL certs somehow.
Theoretically, it should be possible to make a certificate that does both code signing and SSL, but I'm not sure you want that. If something should happen, it would be nice to be able to isolate the two functions. Also, I'm pretty sure you'd have to call the certificate vendors and ask if they did this, and if they don't, having them do it will likely jack up the price quite high.
As far as vendor, things to consider:
The technology is pretty much all the same. These days, aim for a minimum of 128 bit keys, I'd probably bump it up to 256, but I'm paranoid.
Beyond browser acceptabiliy, the only reason to pay more would be name recognition. Among the paranoid security wonks, I'd expect RSA, Thawte, Verisign and GeoTrust to have very good reputations. Probably EnTrust, too. This probably only matters if you are dealing with a security focused product. I think your average user will not be so aware.
From a security geek perspective - you're only as safe as the security of your Root CA (Certificate Authority). For the truly paranoid, the thing to do would be to dig into the background material of how the company hosts its root and issuing CAs, how are they physically securited? network security? personnel access control? Also - do they have public CRLs (Certificate Revocation Lists), how do you get a cert revoked? Do they offer OCSP (Online Certificate Status Protocol)? How do they check out certificate requestors to be sure they are giving the right cert to the right person? ... All this stuff really matters if you are offering something that must be highly secure. Things like medical records, financial managment applications, tax information, etc should be highly protected. Most web apps aren't so high risk and probably don't require this degree of scrutiny.
On that last bullet - if you dig into the Verisigns of the world - the very expensive certs - you're likely to see the value. They have a massive infrastructure and take the security of their CAs very seriously. I'm not so sure about the super-cheap hosting services. That said, if your risk is low, US$300 for an SSL Cert doesn't make much sense compared to US$12.99!!
So for web site / application servers you need an SSL certificate. You do not need an EV certificate. I've used ones from QuickSSL for this, as unlike some of the other cheap certificate providers they don't require the installation of an intermediate certificate on the server - that's a no-one for me.
For signing applications that's a different type of certificate altogether (kind of, it's still an X509 certificate, but the one you use for your web site is not one you can use to sign an application). You need an authenticode signing certificate from the likes of Verisign or Globalsign. These are a magnitude more expensive than a plain old SSL certificate and require you to be an incorporated company and produce those documents.