仅作为域名验证和数据加密也够了，并且浏览器也认它，一般人也不会去看你的证书级别。适合个人和初创网站使用，以后有钱了再申请个收费的替换即可。
我很顺利地申请到了免费的StartSSL证书，分别用在两个子域上。
最后，证书签发给你后，最主要是保护好私钥证书，这个丢失或泄漏就完了。因为如果被别人利用也就毫无安全性了，需要向证书签发机构申请撤销证书并申请新的证书，这当然也是要收费的。
应用规划、配置和调整
并不是说有了SSL证书就没事了，还要考虑应用中的使用问题，需要规划、服务器配置、应用调整等多个环节。
SSL比 http 要消耗更多cpu资源（主要是在建立连接的阶段，之后还要对内容加密），所以对一般网站，只需要对部分地方采用https，大部分开放内容是没必要的，具体取决于你的业务要求。比如对于很多安全要求较低的网站，完全不用https也是可接受的。
某些页面是同时支持 http 和 https ，还是只支持 https、强制 https？
同时支持就是用户用什么协议访问都可以，那么用户的请求主要就是由页面本身的链接引导来的，因为一般用户不会自己特意去修改地址栏的。
一般我们的网站可以做成同时支持http和https，都可以访问。但是这就容易有后面说的混合内容或混合脚本的问题。
还可以规划为部分页面支持 https，一般公开页面不用https，只是将部分地方的链接改为 https 就可以了。专门期望以 https 访问的页面中，引用的绝对URL可以明确的使用 https链接。
是否强制 https ？对于安全性高的网站或网站中的部分页面，可以强制使用https访问， 即使用户在地址栏里手工把 https 改为 http， 也会被自动重定向回 https 上。比如可以通过配置web服务器 rewrite 规则将这些 http url 自动重定向到对应的 https url 上（这样维护比较简单），而不用改应用。
解决混合内容问题(http和https)
混合内容是指：在https的页面中混合了非https的资源请求，比如图片、css、js 等等。如果是混合了非 https 的 js 代码，则被称为混合脚本。
混合内容的危害：如果只是混合了不安全的图片和css，那么受中间人攻击篡改，一般只会影响页面的显示，危害相对小一点。如果是混合了不安全的 js 代码，则这个不安全的 js 可以完全访问和修改页面中的任何内容，这是非常危险的。
另请参看，Chrome对混合脚本危害的说明与提示：Trying to end mixed scripting vulnerabilities
所以，只有页面本身和所有引用的资源都是 https 的浏览器才认为是安全的，只要其中引用了非安全资源（即使图片），浏览器都会给出不安全的提示，特别是有 js 的情况。如果浏览器提示不安全，那样我们就达不到原来目的了。我们费了半天功夫去申请 SSL 证书，配置Web服务器，最后如果因为混合内容而前功尽弃就太糟了。咱继续努力吧，想办法让所有引用资源都是安全的。
理论上，混合了第三方的内容，即使是SSL的第三方内容也不是很好。因为用户信任的是你，而不是第三方，即使第三方也支持https，但你能保证第三方就绝对安全吗。不引用任何第三方才是绝对安全的，但这样太严格了，安全其实也是一个 tradeoff 的问题，需要考虑很多方面的平衡。还好，起码现在浏览器认为已经是安全的了。
引用第三方文件的问题（如 CDN 分发的文件）
简单地说，这个问题要么有第三方提供 https 支持，要么不用它（用自己本地的）。
一般我们会引用由 CDN 分发的文件，比如某个 js 库文件，而不用访问自己网站上的，这样借助 CDN 网络可以加快速度，这当然很好。
但是，如果我们在页面中使用绝对 URL 直接引用这个文件就无法自动使用 https 了！出现了混合协议内容，浏览器又该“变脸”了。
当SSL 遇上CDN 或 其它第三方文件就有点麻烦，因为很多CDN还不支持SSL。如果支持 https 的话就可以直接用 https 的绝对URL了，即使是同时支持http 和 https 的页面，这样做也不算太浪费，起码解决了问题。