Java开发必知的web安全常识

johnny233

已于 2022-07-25 19:18:48 修改

阅读量2k

点赞数 3

分类专栏：理论文章标签： web安全

于 2019-01-20 23:40:50 首次发布

本文链接：https://blog.csdn.net/lonelymanontheway/article/details/84929585

版权

理论专栏收录该内容

17 篇文章 3 订阅

订阅专栏

一个观点：仅仅只会Java语言开发已经远远达不到企业的招聘需求。虽然还不至于要求你面面精通，正经的全栈full-stack开发，但是要广泛涉猎，知识面宽泛。
本文即是对于web开发过程中，涉及安全，证书，加密，密钥，混淆…等概念。
目录

安全
- 定义
攻击
- 攻击分类
- 常见的Web攻击
  - SQL注入攻击
  - XSS攻击
  - CSRF攻击
  - 传输劫持
  - 文件上传漏洞
  - 访问控制
  - DDOS攻击
  - SYN攻击
  - 身份token窃取
  - 账密泄露
  - 暴力破解
防御
- 编码
  - Base64
  - MD5
  - SHA1
  - Blowfish
  - MAC
- 加密
  - DES对称加密
  - AES对称加密
  - 双向RSA加密
- HTTPS
- URL签名
- 双因子认证
证书
- SSL
- 证书标准
- 编码格式
- 常见扩展名
- 证书编码转换
- 获得证书
混淆
- yguard
- ProGuard
- 选择
参考

安全

这个词汇太大，也完全没有必要搞纠结于概念的定义，知道即可。

定义

国际标准化委员会的定义：为数据处理系统和采取的技术的和管理的安全保护，保护计算机硬件、软件、数据不因偶然的或恶意的原因而遭到破坏、更改、显露。
中国公安部计算机管理监察司的定义：计算机安全是指计算机资产安全，即计算机信息系统资源和信息资源不受自然和人为有害因素的威胁和危害。

攻击

攻击分类

常见的Web攻击

SQL注入攻击

定义
攻击者在HTTP请求中注入恶意的SQL代码，服务器使用参数构建数据库SQL命令时，恶意SQL被一起构造，并在数据库中执行。

实例
如String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";如果参数id中是;delete from user;或or 1=1这样，就会返回所有数据

防范
不用拼接SQL字符串。
使用预编译的PrepareStatement。
服务端还有效性检验。（外部都是不可信的，防止攻击者绕过Web端请求）
过滤SQL需要的参数中的特殊字符。比如单引号、双引号。
对 sql 中 in 操作，使用预编译，还是仍然还是通过字符串拼接呢？

XSS攻击

定义
Cross Site Scripting，跨站点脚本攻击，指攻击者通过篡改网页，嵌入恶意脚本程序，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。XSS 可以大概分为三类， DomXSS，反射型XSS和存储型XSS。

实例
假设页面上有一个表单
type="text" name="name"value="awesome"/>
如果，用户输入的不是一个正常的字符串，而是
"/><script>alert("haha")script><!-
此时，页面变成下面的内容，在输入框input的后面带上一段脚本代码。
<inputtype="text"name="name"value="awesome"/><script>alert("haha")script><!-"/>
XSS攻击的威力取决于用户输入的脚本。

危害
攻击者提交恶意的JS代码的评论信息或者反馈信息（这些信息，正常客户端没有做xss校验，会存在客户端注入问题），所有访问者访问该内容时，都会执行这段恶意的JS代码。

防范
前端，服务端同时需要字符串输入的长度限制。
前端，服务端同时需要对HTML转义处理。将其中的"<",">"等特殊字符进行转义编码。

CSRF攻击

Cross-site request forgery，亦XSRF，跨站请求伪造，one click attack/session riding，指攻击者通过跨站请求，以合法的用户身份进行非法操作。攻击者盗用你的身份，以你的名义向第三方网站发送恶意请求。CRSF能做的事情包括利用你的身份发邮件，发短信，进行交易转账，甚至盗取账号信息。容易造成个人隐私泄露以及财产安全。

防范

使用安全框架，例如Apache shiro，Spring Security。
token机制。在HTTP请求中进行token验证，如果请求中没有token或者token内容不正确，则认为CSRF攻击而拒绝该请求。
验证码。通常情况下，验证码能够很好的遏制CSRF攻击，但是很多情况下，出于用户体验考虑，验证码只能作为一种辅助手段，而不是最主要的解决方案。
referer识别。在HTTP Header中有一个字段Referer，记录HTTP请求的来源地址。如果Referer是其他网站，就有可能是CSRF攻击，则拒绝该请求。但服务器并非都能取到Referer。很多用户出于隐私保护的考虑，限制Referer的发送。在某些情况下，浏览器也不会发送Referer，例如HTTPS跳转到HTTP。

传输劫持

不只免费WiFi不安全。收费的、有密码的或是某些电信运营商都不安全。
一般来说劫持有两种：DNS，比如114；有些路由器有CSRF漏洞，可以通过CSRF来设置你的DNS地址。一但你的DNS被修改后，你访问任何网站就悲剧。还有臭名昭著的DNS污染：百度百科

还有一种就是路由器劫持。如免费WiFi；当然如果是运营商，就基本什么都能干了。这一类有很成熟的软件来劫持。一般安全测试用的代理软件，或前端用的Fiddler就是这一类软件。当你是HTTP访问的时候你就什么都让别人知道了。当然并不是说HTTPS就一定安全。

文件上传漏洞

用户上传一个可执行的脚本文件，并通过此脚本文件获得执行服务端命令的能力。

防范

文件上传的目录设置为不可执行。
判断文件类型。在判断文件类型的时候，可以结合使用MIME Type，后缀检查等方式。以及限制上传文件的大小。
对上传的文件类型进行白名单校验，只允许上传可靠类型。
上传的文件需要进行重新命名，使攻击者无法猜想上传文件的访问路径，将极大地增加攻击成本，同时向shell.php.rar.ara这种文件，因为重命名而无法成功实施攻击。
单独设置文件服务器的域名。

访问控制

一般来说，“基于URL的访问控制”是最常见的。

垂直权限管理
访问控制实际上是建立用户与权限之间的对应关系，即“基于角色的访问控制”，RBAC。不同角色的权限有高低之分。高权限角色访问低权限角色的资源往往是被允许的，而低权限角色访问高权限的资源往往被禁止的。在配置权限时，应当使用“最小权限原则”，并使用“默认拒绝”的策略，只对有需要的主体单独配置”允许”的策略，这在很多时候能够避免发生“越权访问”。
Spring Security， Apache Shiro都可以建立垂直权限管理。
水平权限管理
水平权限问题在同一个角色上，系统只验证了访问数据的角色，没有对角色内的用户做细分，由于水平权限管理是系统缺乏一个数据级的访问控制所造成的，因此水平权限管理又可以称之为“基于数据的访问控制”。
举个理解，比如我们之前的一个助手产品，客户端用户删除评论功能，如果没有做水平权限管理，即设置只有本人才可以删除自己的评论，那么用户通过修改评论id就可以删除别人的评论这个就存在危险的越权操作。
这个层面，基本需要我们业务层面去处理，但是这个也是最为经常遗落的安全点。

DDOS攻击

定义

分布式拒绝服务(DDoS，Distributed Denial of Service)攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS攻击，从而成倍地提高拒绝服务攻击的威力。
DDOS 攻击利用目标系统网络服务功能缺陷或者直接消耗其系统资源，使得该目标系统无法提供正常的服务（目的）。
DDoS 攻击通过大量合法的请求占用大量网络资源，以达到瘫痪网络的目的。具体有几种形式：

通过使网络过载来干扰甚至阻断正常的网络通讯；
通过向服务器提交大量请求，使服务器超负荷；
阻断某一用户访问服务器；
阻断某服务与特定系统或个人的通讯。

SYN攻击

属于 DDOS 攻击中的一种具体表现形式。
服务器发送 SYN-ACK 之后，收到客户端的 ACK 之前的 TCP 连接称为半连接(half-open connect)。此时服务器处于 SYN_RCVD 状态。当收到 ACK 后，服务器才能转入 ESTABLISHED 状态。
SYN 攻击指的是，攻击客户端在短时间内伪造大量不存在的 IP 地址，向服务器不断地发送 SYN 包，服务器回复确认包，并等待客户的确认。
由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的 SYN 包将长时间占用未连接队列，正常的 SYN 请求被丢弃，导致目标系统运行缓慢，严重者会引起网络堵塞甚至系统瘫痪。

SYN Flood攻击利用TCP三次握手的缺陷，能够以较小代价使目标服务器无法响应，且难以追查。

标准的TCP三次握手过程如下：

客户端发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号；
服务器在收到客户端的SYN报文后，将返回一个SYN+ACK（即确认Acknowledgement）的报文，表示客户端的请求被接受，同时TCP初始序号自动加1；
客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加1。

经过这三步，TCP连接就建立完成。TCP协议为了实现可靠传输，在三次握手的过程中设置一些异常处理机制。第三步中如果服务器没有收到客户端的最终ACK确认报文，会一直处于SYN_RECV状态，将客户端IP加入等待列表，并重发第二步的SYN+ACK报文。重发一般进行3-5次，大约间隔30秒左右轮询一次等待列表重试所有客户端。另一方面，服务器在自己发出SYN+ACK报文后，会预分配资源为即将建立的TCP连接储存信息做准备，这个资源在等待重试期间一直保留。服务器资源有限，可以维护的SYN_RECV状态超过极限后就不再接受新的SYN报文，也就是拒绝新的TCP连接建立。

SYN Flood正是利用TCP协议的设定，达到攻击的目的。攻击者伪装大量的IP地址给服务器发送SYN报文，由于伪造的IP地址几乎不可能存在，也就几乎没有设备会给服务器返回任何应答了。因此，服务器将会维持一个庞大的等待列表，不停地重试发送SYN+ACK报文，同时占用着大量的资源无法释放。被攻击服务器的SYN_RECV队列被恶意的数据包占满，不再接受新的SYN请求，合法用户无法完成三次握手建立起TCP连接，即这个服务器被SYN Flood拒绝服务。

检测 SYN 攻击：检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源 IP 地址是随机的，基本上可以断定这是一次 SYN 攻击。

DNS Query Flood

打垮DNS服务能够间接打垮一家公司的全部业务，或者打垮一个地区的网络服务。UDP攻击是最容易发起海量流量的攻击手段，而且源IP随机伪造难以追查。但过滤比较容易，因为大多数IP并不提供UDP服务，直接丢弃UDP流量即可。所以现在纯粹的UDP流量攻击比较少见了，取而代之的是UDP协议承载的DNS Query Flood攻击。简单地说，越上层协议上发动的DDoS攻击越难以防御，因为协议越上层，与业务关联越大，防御系统面临的情况越复杂。
DNS Query Flood就是攻击者操纵大量傀儡机器，对目标发起海量的域名查询请求。为了防止基于ACL的过滤，必须提高数据包的随机性。常用的做法是UDP层随机伪造源IP地址、随机伪造源端口等参数。在DNS协议层，随机伪造查询ID以及待解析域名。随机伪造待解析域名除了防止过滤外，还可以降低命中DNS缓存的可能性，尽可能多地消耗DNS服务器的CPU资源。

HTTP Flood

HTTP Flood是针对Web服务在第七层协议发起的攻击。其巨大危害性主要表现在三个方面：发起方便、过滤困难、影响深远。
SYN Flood和DNS Query Flood都需要攻击者以root权限控制大批量的傀儡机。收集大量root权限的傀儡机很花费时间和精力，而且在攻击过程中傀儡机会由于流量异常被管理员发现，攻击者的资源快速损耗而补充缓慢，导致攻击强度明显降低而且不可长期持续。HTTP Flood攻击则不同，攻击者并不需要控制大批的傀儡机，取而代之的是通过端口扫描程序在互联网上寻找匿名的HTTP代理或者SOCKS代理，攻击者通过匿名代理对攻击目标发起HTTP请求。匿名代理是一种比较丰富的资源，花几天时间获取代理并不是难事，因此攻击容易发起而且可以长期高强度的持续。
HTTP Flood攻击在HTTP层发起，极力模仿正常用户的网页请求行为，与网站业务紧密相关，安全厂商很难提供一套通用的且不影响用户体验的方案。在一个地方工作得很好的规则，换一个场景可能带来大量的误杀。
HTTP Flood攻击会引起严重的连锁反应，不仅仅是直接导致被攻击的Web前端响应缓慢，还间接攻击到后端的Java等业务层逻辑以及更后端的数据库服务，增大它们的压力，甚至对日志存储服务器都带来影响。

慢速连接攻击

HTTP协议规定，HTTP Request以\r\n\r\n结尾表示客户端发送结束，服务端开始处理。如果永远不发送\r\n\r\n会如何？Slowloris就是利用这一点来做DDoS攻击的。攻击者在HTTP请求头中将Connection设置为Keep-Alive，要求Web Server保持TCP连接不要断开，随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端，如a:b\r\n，导致服务端认为HTTP头部没有接收完成而一直等待。如果攻击者使用多线程或者傀儡机来做同样的操作，服务器的Web容器很快就被攻击者占满TCP连接而不再接受新的请求。

防范

缩短超时（SYN Timeout）时间
增加最大半连接数
过滤网关防护

身份token窃取

通过document.cookie得到用户的cookie，而在web程序中都是通过cookie验证用户身份，也就是说cookie泄露就可能导致账号直接被黑客访问。

账密泄露

用户喜欢在不同网站使用同一密码，有时候密码很简单，所以账号号被盗就很常见。

暴力破解

黑客使用同一个账号试不同密码，或同一个密码试不同账号，通过社工库，即上面提到的那个账号密码泄露，可以破解很多账号。通过这些账号，特别是邮箱，能够得到很多很多的信息。

总结
还有很多Web安全话题，例如远程执行漏洞、拒绝服务攻击、Session保持攻击等。
吴翰清的《白帽子讲Web安全》。

有攻就有防，下面讲一些防御之术。防御也可以从很多层面分类：

防御

服务端接口通信过程中，一般是明文传输的，没有经过任何安全处理。那么这个时候就很容易在传输过程中被中间者窃听、篡改、冒充等风险。因此，对于敏感信息，以及重要文件就需要进行加密策略，保证通信的安全性。

编码

Base64

Base64是网络上最常见的用于传输8Bit字节代码的编码方式之一，但是它其实并不是一种用于安全领域的加密解密算法。
但是，Base64编码的数据并不会被人用肉眼所直观的理解，所以也有人使用Base64来进行加密解密，这里所说的加密与解密实际是指编码和解码的过程。
Base64加密非常容易被人识别并解码。

MD5

SHA1

Blowfish

Blowfish加密算法的特点：

对称加密，即加密的密钥和解密的密钥是相同的；
每次加密之后的结果是不同的（这也是老夫比较欣赏的一点）；
可逆的，和老夫之前的文章介绍的md5等摘要算法不一样，他是可逆的；
速度快，加密和解密的过程基本上由ADD和XOR指令运算组成；
免费，任何人都可以免费使用不需要缴纳版权费；
BlowFish 每次只能加密和解密8字节数据；

MAC

MAC算法 (Message Authentication Codes) 带秘密密钥的Hash函数：消息的散列值由只有通信双方知道的秘密密钥K来控制。此时Hash值称作MAC。

MAC域（128域）为按照DES算法计算MAC得到的8字节二进制数据的前半部分（4字节二进制数），表示成16进制字符串形式（8个16进制字符）。具体如下：
参与报文校验码（MAC）的数据由三部分产生：初始数据，原始数据，补位数据。
MAC算法如下：
1）算法定义：采用DES CBC算法。
2）初始数据：0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00。
3）原始数据：
4）补位数据：若原始数据不是8的倍数，则右补齐0x00。若原始数据为8的整数倍，则不用不起0X00。
5）密钥：MAC密钥。
MAC的产生由以下方式完成：(最后一组数据长度若不足8的倍数，则右补齐0x00；若数据长度为8的整数倍，则无需补充0x00)。

其他

加密

加密算法的种类：

DES对称加密

将敏感的信息在通信过程中通过DES进行加密传输，然后在客户端和服务端直接进行解码。
那如何保管密钥呢？因为客户端和服务端都需要进行解码，所以两者都要存一份密钥。其实，还有一种方案是通过服务端下发，但是下发的时候通信的安全性也是没有很好的保障。
DES对称加密也是存在一定的安全隐患：密钥可能会泄漏。

AES对称加密

AES和DES类似，相较于DES算法而言，AES算法有着更高的速度和资源使用效率，安全级别也较之更高。一般情况下，用于文件的加密。仍然存在一个相同的问题：密钥可能会泄漏。

双向RSA加密

RSA双向认证，就是用对方的公钥加密是为了保密，这个只有对方用私钥能解密。用自己的私钥加密是为了防抵赖，能用我的公钥解开，说明这是我发来的。
例如，支付宝的支付接口就是非常典型的RSA双向认证的安全方案。此外，我们之前的教育资源、敏感验证码出于安全性考虑都借鉴了这个方案。

加密错误

加密错误，也就是bad practice：

硬编码密钥

HTTPS

HTTPS的价值在于：
内容加密，第三方无法窃听。
身份认证，一旦被篡改，通信双方会立刻发现。
数据完整性。防止内容冒充或者篡改。
这个方案，没法保护敏感数据，如果需要对敏感数据进行加密，还是需要考虑加密方案。

URL签名

基于OAuth2协议，进行URL签名。URL签名只能垂直权限管理，但没法保护敏感数据，如果需要对敏感数据进行保护，还是需要考虑加密方案。

双因子认证

在使用GitLab时，随意翻阅其help文档，看到这个Two-factor Authentication，2FA。在不同的应用领域，2FA可能略有些许不同，在GitLab中，指的是<internal_gitlab_hostname>help/profile/two_factor_authentication。

双因子认证（2FA）是指结合密码以及实物（信用卡、SMS手机、令牌或指纹等生物标志）两种条件对用户进行认证的方法。这种方法已经为企业所采用，特别是在远程访问时，但在其它领域应用还很有限。双因子认证的推广之所以受阻，主要在于其需要使用额外的工具并且为IT和技术支持人员带来负担。其批评者还指出这种方法也容易遭受攻击，即在非常小的时间窗口内，易受到中间人（man-in-the-middle）攻击（这也是采用严格SSL处理的更多原因）。除了这些障碍以外，实际上现在我们已经开始认识到，不采用双因子认证所带来的隐含成本远远比采用双因子认证所需要的成本高得多。受到欧洲银行业的影响，以及欺诈行为带来的成本不断增加，美国金融机构将加快采用双因子认证的步伐，这一行动将会促使消费者更快习惯这一方法。为减轻必须携带专用双因子令牌设备所带来的阻力，可以利用现在无处不在的移动计算平台（如支持Java的手机或通过短信息服务传递的一次性口令）作为双因子客户平台。同时，就象欺诈带来的成本促使银行业采用双因子认证一样，这也是电子商务企业采用双因子认证的主要动力，电子支付行业团体，如PCI和APACS已经开始强制使用双因子认证。这一机制很快将会成为认证领域的通用作法，不久以后我们就会对仅仅采用密码认证的系统产生强烈的不信任感。
一般来说，在安全方面必须接受这样一个事实：并不存在任何形式的硬件或软件能够提供万能的安全解决方案。但这并不妨碍采取相应的安全措施：大门上的锁对“敲锁法”来说可能并不安全，而大门本身也耐不住斧头、锯子、火把或炸药的攻击，但即使这样你仍然不会因为安全系统不完美而始终大门敞开，或者根本不上锁。实际上，多采取一些安全措施会在攻击者和保护者之间的这场战斗中会增加一些胜算。当然，前提是这些措施是有效的，否则会造成一种虚假的安全感，反而会使事情恶化，因为用户会因此而警惕性变低。认识到这一点，最好的方式可能是改变游戏的规则，集中精力使数据窃取型犯罪不那么有利可图。

有一个开源的代码实现，可供参考：two-factor-auth，实现Time-based One-time Password算法。

证书

SSL

SSL，Secure Sockets Layer；TLS，Transport Layer Security。HTTP协议默认情况下是不加密内容的，这是不安全的。加密之后，即得到HTTPS==HTTP+SSL。
SSL是一种规范，理论上来说是安全的，很难破解，但SSL的实现（如OpenSSL）就可能有些漏洞，如著名的”心脏出血”。

证书标准

X.509 – 这是一种证书标准，主要定义证书中应该包含哪些内容。参考RFC5280，SSL使用的就是这种证书标准。

编码格式

同样的X.509证书，可能有不同的编码格式，目前有以下两种编码格式。

PEM – Privacy Enhanced Mail，打开看文本格式，以—–BEGIN…开头，—–END…结尾，内容是BASE64编码。
查看PEM格式证书的信息：openssl x509 -in certificate。pem -text -noout
Apache和*NIX服务器偏向于使用这种编码格式。
DER – Distinguished Encoding Rules，二进制格式不可读。
查看DER格式证书的信息：openssl x509 -in certificate。der -inform der -text -noout
Java和Windows服务器偏向于使用这种编码格式。

文件扩展名

两种编码格式PEM和DER，但文件扩展名并不一定就叫"PEM"或"DER"，常见的扩展名除PEM和DER还有以下这些，它们除了编码格式可能不同之外，内容也有差别，但大多数都能相互转换编码格式。

CRT，常见于类Unix系统，有可能是PEM编码，也有可能是DER编码，大多数应该是PEM编码。
CER，常见于Windows系统，同样可能是PEM、DER编码，大多数应该是DER编码。
KEY，通常用来存放一个公钥或者私钥，并非X.509证书，编码同样可能是PEM/DER。
查看KEY的办法：openssl rsa -in mykey.key -text -noout
如果是DER格式：openssl rsa -in mykey.key -text -noout -inform der
CSR – Certificate Signing Request，即证书签名请求，这个并不是证书，而是向权威证书颁发机构获得签名证书的申请，其核心内容是一个公钥(当然还附带一些别的信息)，在生成这个申请的时候，同时也会生成一个私钥，私钥要自己保管好。
查看方法：openssl req -noout -text -in my.csr (DER格式加上-inform der)
PFX/P12 – predecessor of PKCS#12，对*nix服务器来说，一般CRT和KEY是分开存放在不同文件中的，但IIS则将它们存在一个PFX文件中，PFX通常会有一个”提取密码”，你想把里面的东西读取出来的话，它就要求你提供提取密码，PFX使用的时DER编码，把PFX转换为PEM编码：openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes
这个时候会提示你输入提取代码。 for-iis.pem就是可读的文本。
生成pfx的命令类似这样:openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt
其中CACert.crt是CA(权威证书颁发机构)的根证书，有的话也通过-certfile参数一起带进去。PFX其实是个证书密钥库。
JKS，Java Key Storage，Java的专利，跟OpenSSL关系不大，利用JDK的keytool工具，可以将PFX转为JKS，keytool也能直接生成JKS。

Pfx

百科：

公钥加密技术12号标准（Public Key Cryptography Standards #12，PKCS#12）为存储和传输用户或服务器私钥、公钥和证书指定一个可移植的格式。它是一种二进制格式，这些文件也称为PFX文件。开发人员通常需要将PFX文件转换为某些不同的格式，如PEM或JKS，以便可以为使用SSL通信的独立Java客户端或WebLogic Server使用。
一种Microsoft协议，使用户可以将机密信息从一个环境或平台传输到另一个环境或平台。使用该协议，用户就可以安全地将个人信息从一个计算机系统导出到另一个系统中。

cer和pfx区别

作为文件形式存在的证书一般有这几种格式：
1.带有私钥的证书
　　由Public Key Cryptography Standards #12，PKCS#12标准定义，包含公钥和私钥的二进制格式的证书形式，以pfx作为证书文件后缀名。
2.二进制编码的证书
　　证书中没有私钥，DER 编码二进制格式的证书文件，以cer作为证书文件后缀名。
3. Base64编码的证书
证书中没有私钥，BASE64 编码格式的证书文件，也是以cer作为证书文件后缀名。

只有pfx格式的数字证书是包含有私钥的，cer格式的数字证书里面只有公钥没有私钥。
　　在pfx证书的导入过程中有一项是“标志此密钥是可导出的。这将您在稍候备份或传输密钥”。一般是不选中的，如果选中，别人就有机会备份你的密钥。如果是不选中，其实密钥也导入了，只是不能再次被导出。这就保证密钥的安全。
　　如果导入过程中没有选中这一项，做证书备份时“导出私钥”这一项是灰色的，不能选。只能导出cer格式的公钥。如果导入时选中该项，则在导出时“导出私钥”这一项就是可选的。
　　如果要导出私钥（pfx)，是需要输入密码的，这个密码就是对私钥再次加密，这样就保证私钥的安全，别人即使拿到你的证书备份（pfx)，不知道加密私钥的密码，也是无法导入证书的。相反，如果只是导入导出cer格式的证书，是不会提示你输入密码的。因为公钥一般来说是对外公开的，不用加密。

.pfx格式转.key和.crt文件

IIS导出的文件是.pfx格式，Apache的SSL证书是是.key和.crt文件。只需将.pfx文件转换为.key+.crt文件，将可以在Apache上安装。
set OPENSSL_CONF=openssl.cnf
openssl pkcs12 -in myssl.pfx -nodes -out server.pem
openssl rsa -in server.pem -out server.key
openssl x509 -in server.pem -out server.crt
(server.pfx是IIS导出的文件，利用openssl导出server.key和server.crt)

以上转换也可在Linux上直接执行命令
生成rsa密钥
openssl genrsa -des3 -out prikey.pem
去除掉密钥文件保护密码
openssl rsa -in prikey.pem -out prikey.pem
分离出公钥
openssl rsa -in prikey.pem -pubout -out pubkey.pem(获取证书中的公钥 openssl req -in myreq.pem -out -pubkey.pem)
对文件进行签名
open rsautl -sign -inkey prikey.pem -in a.txt -out sig.dat
验证签名
openssl rsautl -verify -inkey prikey.pem -in sig.dat
用公钥对文件加密
openssl rsautl -encrypt -pubin -inkey pubkey.pem -in a.text -out b.text
用私钥解密
openssl rsautl -decrypt -inkey prikey.pem -in b.text
用证书中的公钥加密
opensll rsautl -encrypt -certin -inkey cert1.pem -in a.txt

或者
生成一个没有加密的ca私钥
openssl genrsa -out ca.key.pem 1024
生成ca对应的csr文件
openssl req -new -key ca.key.pem -out ca.csr
自签名
openssl x509 -in ca.csr -out ca.cer -req -signkey ca.key.pem -days 7300 -extensions v3_ca
生成DER格式的私钥
openssl pkcs8 -topk8 -inform PEM -outform DER -in ca.key.pem -out ca.private.der -nocrypt
读取证书的内容，显示在屏幕上
openssl x509 -in server.cer -noout -subject -nameopt RFC2253
将der格式的证书转成pem格式
openssl x509 -inform PEM -outform DER -in server.der -out server.pem

证书编码转换

PEM转为DER：openssl x509 -in cert.crt -outform der -out cert.der
DER转为PEM：openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
(要转换KEY文件也类似，只不过把x509换成rsa，要转CSR的话，把x509换成req…)

获得证书

向权威证书颁发机构申请证书
用这命令生成一个csr: openssl req -newkey rsa:2048 -new -nodes -keyout my.key -out my.csr
把csr交给权威证书颁发机构，权威证书颁发机构对此进行签名，完成。保留好csr，当权威证书颁发机构颁发的证书过期的时候，你还可以用同样的csr来申请新的证书，key保持不变。

或者生成自签名的证书
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem

在生成证书的过程中会要你填一堆的东西，其实真正要填的只有Common Name，通常填写你服务器的域名，如”yourcompany.com”，或者你服务器的IP地址，其它都可以留空的。

生产环境中还是不要使用自签的证书，否则浏览器会不认，或者如果你是企业应用的话能够强制让用户的浏览器接受你的自签证书也行。向权威机构要证书通常是要钱的，但现在也有免费的，仅仅需要一个简单的域名验证即可。