I was thinking, since I controll the app and what site it points too (and since I of course control the server as well), is it a security issue if the SSL certificate is self signed? The entire point of having a verified certificate is so people know that you are who you say you are right? When I controll who people are talking too anyway, what use is it to have a verified certificate?
Related
I have a portofolio website runing on a IIS Windows server if that matters.But some people complained that they get "website unsafe" when navigating the website.I personaly didnt get that error , and I tried the website on other diveces and they didnt get it either.
Could have something to do with SSL Certificate ? I didn't bought one ,but I have a self signed certificate according to ssl checker
.Do I need to buy a trusted SSL Certificate ? Or is there another problem ?
On my website i have a "Contact us" page with a web form that users should fill with name,email...
EDIT: I don't know if it's ok to post the website link here, if it's needed let me know .
EDIT: Link to website here.
This is a general problem with self-signed certificates, as the visitors of you website, or their browser, are not able to verify the identity of your server. The reason for this is, that there is no Certification Authority that signed it, thus the browser does not have a (root) certificate that is in the chain of trust linked to your certificate.
This problem with self-signed certificates is well explained in this post
The risks are for the client. The point of the SSL server certificate is that it is used by the client to know the server public key, with some level of guarantee that the key indeed belongs to the intended server. The guarantee comes from the CA: the CA is supposed to perform extensive verification of the requester identity before issuing the certificate.
When a client (the user and his Web browser) "accepts" a certificate which has not been issued by one of the CA that the client trusts (the CA which were embedded in Windows by Microsoft), then the risk is that the client is currently talking to a fake server, i.e. is under attack. Note that passive attacks (the attacker observes the data but does not alter it in any way) are thwarted by SSL regardless of whether the CA certificate was issued by a mainstream CA or not.
On a general basis, you do not want to train your users to ignore the scary security warning from the browser, because this makes them vulnerable to such server impersonation attacks (which are not that hard to mount, e.g. with DNS poisoning). On the other hand, if you can confirm, through some other way, that the certificate is genuine that one time, then the browser will remember the certificate and will not show warnings for subsequent visits as long as the same self-signed certificate is used. The newly proposed Convergence PKI is an extension of this principle. Note that this "remembered certificate" holds as long as the certificate is unchanged, so you really want to set the expiry date of your self-signed certificate in the far future (but not beyond 2038 if you want to avoid interoperability issues).
It shall be noted that since a self-signed certificate is not "managed" by a CA, there is no possible revocation. If an attacker steals your private key, you permanently lose, whereas CA-issued certificates still have the theoretical safety net of revocation (a way for the CA to declare that a given certificate is rotten). In practice, current Web browser do not check revocation status anyway.
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 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.
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'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.