I am developing a site for a school which will allows students to make an application using PIN and Serial No. I chooses Godaddy to Host the site on Ultimate plan, so is it necessary for me to include Standard SSL for the hosting plans since am using PINS or Standard SSL is meant for secure transanctions that includes using Credit cards?
Do you need SSL?
I assume that said applications will contain personal data, so your web application should use SSL to prevent third parties (such as other people on the same insecure wireless network as the student) from accessing that data. Depending on your jurisdiction, you may also be required by law to enable SSL.
Do you need GoDaddy Standard SSL?
From a quick look, it appears that the product you are referring to is a domain-validated certificate (i.e. they only verify that you own the domain, not that you are who you say you are). You can get those significantly cheaper elsewhere, and if you launch after mid-November, you can get a free one with automatic renewal from the Let's Encrypt project.
You should also check if you can get a certificate from your school. If your application will be hosted under a domain that is already being used for the school, they may have an existing certificate that you can use. Some schools (e.g. most German universities) also have their own certificate authorities which can issue SSL certificates for arbitrary websites.
If you get your certificate from GoDaddy as well, you pay more for the convenience of not having to learn as much.
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 looking to buy SSL certificate for PWA.
The domain is bought from godday, where I checked a couple of options:
https://in.godaddy.com/web-security/ssl-certificate?isc=sshl6in01
https://www.comodo.co.in/ssl-certificates
They have got multiple types of certificates.
Which one is best suited for PWA?
In my case, the app takes the user name and number and saves them in the DB, and it also shows some data from DB to the user.
Service workers, as part of PWAs, do not need special SSL certificates to work. They simply need a working secure connection (HTTPs).
There are many hosting platforms offering already a SSL certificate out of the box. Of course it depends on your requirements and constrains about hosting providers. However if you are free in the choice of the hosting solution, I would suggest to start with a simple solution. This as general advice, also in line with what Paul suggested in his comment.
Firebase hosting is an example (here more details on how to use a custom domain):
I have a client that needs SSL to protect online donations, but I have limited experience with how/when to use SSL.
I understand that in purchasing a certificate that I am assigning that certificate to an entire domain (IP address really). Is there a way to isolate the encryption to only a single page of the website, or should I just go ahead and secure the entire site even though only one page needs it?
Unsure of best practice here. Please advise.
SSL incurs quite a bit of extra processing time. For low bandwidth sites, the extra processing required by SSL is not really noticeable. But for sites with heavy traffic like Facebook, Twitter and Flickr, the load caused by SSL is heavy enough that they would have to use dedicated SSL encoding/decoding hardware.
So basically yes, it makes sense to minimize the number of pages using SSL. That is why you often see banking sites only protect the actual account pages via https. The home/landing page is usually plain old http.
On the other hand, unless you really are a site like Twitter or Facebook or Gmail, worrying about this is a bit of a premature optimization. First do it simple if you can. Be aware of this issue and be aware of upgrade strategies when your site finally get heavy traffic.
My boss has a saying:
This is a happy problem to have. First solve the sad problem of
not having enough users then you'd be happy to have a problem that
requires you to refactor your architecture.
You don't encrypt a website with SSL. you encrypt the connection. Therefore if you have SSL enabled for the webserver simply adding https:// to the url will encrypt the connection and whatever page the url points to will be encrypted while in transit.
so
https://www.website.com/index.html is encrypted and http://www.website.com/index.html is NOT encrypted
I prefer for that to never happen so I always put my encrypted pages in a subdomain eg.
https://secure.website.com/index.html
SSL comes with a couple of gotcha's
1/ a basic SSL certificate will only be valid for a specific domain name so if the certificate for is www.website.com and someone follows a link for website.com a warning will be displayed. (see note below)
2/ SSL requires a dedicated IP (which you appear to have). that means you may have problems if you are on a shared platform. this is because in HTTP the host or domain name is part of the headers but the headers are encrypted so the server can't know where to route the request to. (see note below)
It sounds like you really need to employ the services of someone familiar with ecommerce and SSL to help you. navigating the minefield with limited knowledge and forum responses is not the safest thing to do. especially if financial transactions are taking place because there are other requirements that must be considered such as the legal requirements in storing and using financial information such as credit card numbers.
DC
Addendum:
For donations consider Paypal. They have a complete donation solution and more people will trust it than a roll your own solution.
EDIT 2016:
The world moves on and some of the advice above is not as true as it was when originally answered.
SSL no longer requires a dedicated IP address. SNI (Server name indication) resolves that and is almost universal now (IE8 on winXP does not support it and a few phones).
You will find most certificate vendors now include the main domain name as a SAN (subject alternative name) in a certificate. Which is to say they will provide a certificate for both www.website.moc and website.moc if you get a certificate for www.website.moc. Do not assume this, make sure your certification authority specifies it.
also, you mentioned that an SSL certificate protects an IP address. This is incorrect. An SSL certificate corresponds to a domain. Many schemes exist where several domains share a single IP address. If one of these shared domains has an SSL certificate, that certificate is only good for that domain, not the others.
Cookie security is the main thing that I'd point to for your approach.
A user that logs in on your secure login page gets a cookie for their session, right? That cookie's then being transmitted in plain text for someone watching the wire (Firesheep) to intercept and steal the session.
There is additional overhead in terms of negotiation time and CPU load from SSL, but it's rather minimal. If there's anything sensitive going on on your site, just use SSL everywhere.
The other answers are inaccurate in this regard: An SSL certificate binds to BOTH a dedicated IP address that is assigned to a static single domain name, unless you purchase a wild card SSL. Both the domain name and IP must match the certificate.
I'm writing a billing module for a startup i'm working on. It's my first time buying an SSL cert. I only need a cert for a single domain. Is the standard SSL cert from godaddy ($29.99/yr) all that I need?
I plan to get an authorize.net compatible merchant account and didn't know if they would require the deluxe or premium certs. I'm side strapping this business so I'm trying to do it on the cheap. Thanks
Different certificates sold through the lucrative business of Certificate Authorities carry different price tags, for a few reasons. The most noticeable to clients visiting your web site is how much information the CA decided to "assure", based on how much you paid.
If you could convince your clients that a self-signed certificate has indeed not been compromised, and guarantees no eavesdropping-on-the-internet, then you could get away with $0 certificate cost.
However, users want more than that.
The GoDaddy standard certificate offers domain validation. GoDaddy is recognized by browsers, and will tell your clients that yes, we issued this certificate to https://billing.yourhost.domain, and if you see a website called https://webstore.yourhost.domain using the same certificate, there will be an error in the validation.
Depending on your needs to give client assurance, you may require/desire a certificate for which GoDaddy or another provider will validate a point-of-contact with a business so that when I visit https://billing.washingtonwidgets.com, I can see that this Web site is registered to "Washington Widgets, Ltd.", as opposed to someone who can buy a DNS name for $5 and open up https://paymeinstead.therealwashingtonwidgets.com. This is more "assurance" against spoofers. A spoofer may be able to get a domain validated certificate for a web site which carries a similar name to yours. This extra "assurance" costs more, and several large companies will back the assurance with a warranty, too.
A new type of SSL called EV SSL is marketed to represent one of the highest levels of assurity, and browser vendors are participating in presenting notification to users in a clear manner when a site uses an EV SSL certificate.
An aside from SSL: Now, do you need your own site to be secure? Or can you write a billing module and send a ticket off to a third party ticket billing site such as PayPal, authorize.net, etc. The term you want to look for is payment gateway. Often times these services will charge a small commission, instead of a yearly premium for a similar, but different kind of assurance. They usually offer API's that you can link through your application to create an end-to-end billing experience.
You need to buy a cert from a trusted root authority for your specific domain. I would talk to your hosting provider, as they will need to install the cert etc and may have a mechanism in place for you to go and buy one.
If you're really trying to do it on the cheap, I would def recommend paypal or any other similar service over rolling your own.
Edit: Also, this isn't programming related, maybe something along the lines of "What would a low cost, easy to implement, billing solution be?"
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.