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 zero experience with setting up root and intermediate certificates on web servers. Paypal is implementing security changes for all merchants to use SHA256, TLS1.2 and this specific Verisign G5 certificate. They have set up their sandbox with new requirements so we can test our current servers and code to ensure compliance come Sept 2016. I use GoDaddy shared hosting. They have the first two in place but they use their own certificates. Paypal insists merchants must use this particular G5 root certificate and GoDaddy insists that what they have is fine. But can't get them working. All is fine with current environment. I've upgraded to a new CPanel shared hosting account to test if that can be a solution but that is not working with sandbox either. Paypal has sent me two certificates, from what I understand I have to use one for my application code and the other has to be the server root certificate. The root is what I'm having a problem with. Conflicting stances from both Paypal and GoDaddy and with Paypal Merchant Tech Support now not accepting any calls, only tickets that take days to communicate, it will put many merchants in a problem situation. Has anyone got any advice on how these certificates work, how many I actually need and how I can get the root certificate installed on GoDaddy's shared hosting platform?
After much communication and trial and error, it looks like GoDaddy's newer accounts are working fine with Paypal's sandbox. So long as the platform is TLS1.2 with SHA2(256) and there is 2048-bit encryption on their SSL, it seems to work. Paypal's documentation that specifies that the "Verisign 2048 G5 certificate must be used" should say "or equivalent".
StartSSL.com seems to be selling cheap SSL certs, but I wonder if anyone actually have experience using their certs.
StartSSL™ Verified StartSSL™ Verified (Class 2) digital certificates are ideal for authentication, B2B and B2C transactions, protection of electronic mail and signing of object code and macros. More than that, StartSSL™ Verified provides a level of flexibility and support options not found anywhere else. StartSSL™ Verified supports:
Web server certificates (SSL/TLS)
Wild cards (*.domain.com)
Multiple domains (DNS Alt Names)
128/256-bit encryption
Object Code Signing
Client and mail certificates (S/MIME)
US $ 10,000 insurance guaranteed
Certificates 2 Years valid (730 days)
Is it safe to share personal passport information and company information with them for personal/organization validated certs?
(their website looks crapy and help email bouncing)
I am interested in signing code, and if that works for web server as well, that would be great.
Any other alternatives?
Edit in February 2018
As noted by others in the comments, StartSSL certificates are no longer trusted by browsers, and they are no longer issued. I recommend taking a look at Let's Encrypt instead.
Original answer
I just signed up with them. After submitting my passport (with some info blacked out, just in case) I got a call almost instantly from a representative wanting to verify some information.
Haven't found any info about them being shady, and given that they have been accepted as a root CA by Microsoft, I believe they are legit.
I know this is not a specific question, but I'm reading about this subject for about an hour and can't find any BASIC information about it?
How does SSL work? What's a private and public key? Why do you have to buy a certificate at a company and what's the difference between signing one yourself? What is such certificate anyway?
I've read several websites, the wikipedia info, other threads on Stack Overflow, but it's very confusing. It seems nobody can explain the BASICS with a simple example. I have to write a small text about the basics of SSL, but everything is very confusing.
First I read a lot of info about public and private keys in SSL, then the next site tells me SSL doesn't use this, but uses a symmetric key (how does this work?)
If anyone got a link to a website which explains the basic concepts of SSL, I would be very happy.
Thank you!
Try reading our introductory article (and some other articles in the same knowledgebase section). But in general it is important to know the basics of cryptography and some PKI before going for SSL. You can't start from scratch and understand SSL in an hour.
I wanted to know the same thing recently. I was pointed towards this podcast. I listened to it twice and it's sunk in.
Check out Security Now Espisode 195 (The SSL/TLS Protocol) at http://www.grc.com/securitynow.htm
It's not a quick answer but this podcast will give you a really good grounding.
Good luck.
SSL (Secure Sockets Layer) encrypt information that website visitors enter on your website.
In order to secure your site, you'll need an SSL certificate.
There are two types of SSL certificates.
Self Signed - They can be obtained for free using software like Open SSL. These type of certificates provide encryption, but it's not authenticated like authority-signed certificates.
A website which use a self-signed certificate will show an error message when a user submit information that it has not been verified by an authorized party.
Authority Signed - it's not free and have a yearly fee. An authority-signed certificate also comes with a warranty in most cases, which means if the site is compromised, you will be paid for the damage caused up to a certain amount.
You can get an authority signed SSL certificate from any authorized SSL certificate 3rd party.
All data entered by your users will by encrypted and it keeps hackers from seeing private information like credit card and banking information, even social media postings.
Having your site secured, makes customers feel secure and comfortable entering personal information.
I hope this answer your question.
Regards
Marietha
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I would like to have the authentication and registration parts of my website encrypted (for obvious reason). This site is currently and older site which some friends and I started in middle school and still use today. I may or may not register it to be a Non-Profit Organization in the near future, but either way, a CA costs money and the organization doesn't have any and we are currently college kids.
Verisign is unreasonable and GoDaddy is $30/year. GoDaddy isn't too unreasonable, and I think their certs are accepted by most web browsers. The thing with GoDaddy is that I don't know why they have different SSL products (i.e.: why is it cheap to not verify me? does this have any implications on the cert and how the browser treats it if it just contains a domain name?)
Also, is there an issue with using my own cert? Could the login page be http, and have a line stating that I use a self-signed cert and here is it's fingerprint and then post the form to an https page? Safari's method isn't too bad or sound too scary. I'm afraid, however, that firefox 3's method will scare people away and give me a tonne of emails saying that my site is being hacked or something. I don't know how IE responds to self-signed certs. (There is also the issue of why pay for something I can create myself with no effort, but I'm not going to pose the philosophical part of it, this is a more practical question.)
In sum, do I give GoDaddy $30 a year or do I just tell people in a small paragraph what I'm doing and give the few people that will actually want my fingerprint it?
Edit: Some on a forum I was reading for more info mentioned that GoDaddy certs are only given if it's on a GoDaddy server, which this isn't. Two things: (1) is this true? and There are other CA's at about the same price, so the argument should still be the same.
There's a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA's like GoDaddy and Verisign, and that you have to live with browser warnings/exceptions if you use them; this is incorrect.
If you securely distribute a self-signed certificate (or CA cert, as bobince suggested) and install it in the browsers that will use your site, it's just as secure as one that's purchased and is not vulnerable to man-in-the-middle attacks and cert forgery. Obviously this means that it's only feasible if only a few people need secure access to your site (e.g., internal apps, personal blogs, etc.).
In the interest of increasing awareness and encouraging fellow small-time bloggers like myself to protect themselves, I've written up a entry-level tutorial that explains the concepts behind certificates and how to safely create and use your own self-signed cert (complete with code samples and screenshots) here.
The SSL certificate solves two purposes: encryption of traffic (for RSA key exchange, at least) and verification of trust. As you know, you can encrypt traffic with (or without, if we're talking SSL 3.0 or TLS) any self-signed certificate. But trust is accomplished through a chain of certificates. I don't know you, but I do trust verisign (or at least Microsoft does, because they've been paid lots of money to get it installed in their operating systems by default), and since Verisign trusts you, then I trust you too. As a result, there's no scary warning when I go to such an SSL page in my Web browser because somebody that I trust has said you are who you are.
Generally, the more expensive the certificate, the more investigating that the issuing certificate authority does. So for the Extended Validation certificates, the requesters have to submit more documents to prove that they are who they say they are, and in return they get a bright, happy green bar in modern Web browsers (I think Safari doesn't do anything with it quite yet).
Finally, some companies go with the big boys like Verisign purely for the brand name alone; they know that their customers have at least heard of Verisign and so that for people shopping on their online store, their seal looks a little less sketch-ball than, say, GoDaddy's.
If the branding is not important to you or if your site is not prone to phishing attacks, then the cheapest SSL cert that you can buy that has its root installed in most Web browsers by default will be fine. Usually, the only verification done is that you must be able to reply to an e-mail sent to the DNS's administrative contact, thus "proving" that you "own" that domain name.
You can use those cheap-o certificates on non-GoDaddy servers, sure, but you'll probably have to install an intermediate certificate on the server first. This is a certificate that sits between your cheap-o $30 certificate and the GoDaddy "real deal" root certificate. Web browsers visiting your site will be like "hmm, looks like this was signed with an intermediate, you got that?" which requires may require an extra trip. But then it'll request the intermediate from your server, see that it chains up to a trusted root certificate that it knows about, and there is no problem.
But if you are not allowed to install the intermediate on your server (such as in a shared hosting scenario), then you are out of luck. This is why most people say that GoDaddy certs can't be used on non-GoDaddy servers. Not true, but true enough for many scenarios.
(At work we use a Comodo certificate for our online store, and a cheapo $30 GoDaddy cert to secure the internal connection to the database.)
Edited in italics to reflect erickson's insightful clarifications below. Learn something new every day!
Get a certificate from Let's Encrypt, a free CA this new decade, which is widely supported by browsers.
I haven't tried them yet, but StartCom was mentioned in a response to a similar question. Apparently you can get a one year certificate for free, and it's accepted by Firefox 3.
Even if you have to pay, I would suggest using a CA rather than self-signed certificates. Some people won't see your explanation, and a fake site could post their own fake certificate's fingerprint just like you propose. I doubt the average user knows what a certificate fingerprint is or how to check it.
Instead of creating a self-signed cert, create a self-signed CA, and sign your HTTPS certificate with that. It's easier to ask users to install a CA than a single server cert, and you can create new certs (eg. for subdomains, or to update expired certs) without users having to install a server cert again.
You can then decide later whether it's worth the $30 to switch from a cert signed by your own CA to the same cert signed by GoDaddy or whoever.
Either way, don't have an HTTP page with a form posted to HTTPS. The user cannot see that that's where it's going; they'd have to view source to check the form hasn't been hijacked to point elsewhere and no-one's going to do that. You would have to have an HTTP front page with the CA link and a separate link to the HTTPS login form.
Asking users to install a CA with a cert downloaded via plain HTTP is a bit naughty: if there were a man-in-the-middle they could replace your CA on the fly and hijack the ensuing HTTPS connections. The chances of this actually happening are quite low as it would have to be a targeted attack as opposed to plain old automated sniffing, but really you ought to be hosting the CA download link on some other HTTPS-protected service.
Customer acceptance is a matter only you can answer, knowing who your users are. Certainly the Firefox interface is excessively scary. If CAs like GoDaddy are down to $30 these days I would probably go for it; it used to be a lot, lot worse.
Assuming support on old and niche browsers is not much of an issue, just go for the cheapest CA available. You are supposed to be paying to have the CA properly verify who you are, but in practice that's not the way it works and it never has been, so paying extra for more thorough checks gets you almost nothing. Verisign's extortionate prices survive through corporate inertia alone.
CAs are there to receive money for doing nothing but owning a few hundred bits of private key. The identity-verifying stuff that was supposed to have been part of the CA mandate has been moved to EV certificates. Which are even more of a rip-off. Joy.
Self-signed certificates are insecure. Yes, really. "At least it's encrypted" isn't helping at all. From the article:
World-class encryption * zero authentication = zero security
If your website is for you and a few of your friends, then you might create your own CA and distribute your certificate to friends.
Otherwise either get a certificate from known CA (for free) or don't bother with self-signed certificates at all, because all you'd get is a false sense of security.
Why just encrypted traffic is not secure? You're always allowing the other end to decrypt your traffic (you have to, otherwise you'd be sending gibberish).
If you don't check who's on the other end, you're allowing anybody to decrypt your traffic. It doesn't make a difference if you send data to an attacker securely or not securely — the attacker gets the data anyway.
I'm not talking about checking whether e.g. paypal.com belongs to a trustworthy financial institution (that's a bigger problem). I'm talking about checking whether you're sending data to the paypal.com, or just to a van around the corner that sends a certificate saying "yeah, I'm like totally paypal.com and you have my word that it's true!"
I just finally broke down and switched my server from self-signed to a GoDaddy cert last night and it wasn't that big a deal, aside from their process not being as clear as it could be. $30/year is a reasonable cost and using the cert on a non-GoDaddy server is not an issue.
If you're going to be talking SSL to the public, get a real cert signed by a real CA. Even if you're working for minimum wage, you'll save more than $30/year worth of wasted time in dealing with user fears or distrust, and that's even before considering any possible lost revenue due to them being scared away from your site.
To answer your question about Internet Explorer, it will warn users about any site whose certificate is not signed by an IE-known (unfortunately called "trusted") CA. This includes for your own CA and for self-signed certificates. It will also make a warning if the domain in the certificate is not the one being accessed.
If this is a private site, you may not care so long as you are getting link-level encryption (and are you that fearful of someone sniffing your traffic?). If there is public access and you want SSL, then get a signed certificate from a recognized CA, as others have already advised.
If that van around the corner is capable of hijacking your internet connection already, you've got worse problems than self-signed certificates.
Banks should use client certificates for authentication. That would make it impossible for that van to do anything.... since it doesn't have the banks private key.
Self-signed certs are perfectly fine... assuming your internet connection hasn't been compromised. If your connection has been compromised... you're probably dogged anyway.