V2EX › neilp 的所有回复 › 第 30 页 / 共 35 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 22 23 24 25 26 27 28 29 30 31 ... 35

❮

❯

2016-02-07 18:46:07 +08:00

回复了 Livid 创建的主题 › SSL › letsencrypt.sh

@DesignerSkyline

是啊，哈哈，　谁规定的程序员就过年一定要宅在家呢．

接下来另一个 feature 是要支持 ECDSA 证书. 这个优先级比 revoke 要高.

其实 revoke 的作用真的不大.

2016-02-07 18:38:16 +08:00

回复了 Livid 创建的主题 › SSL › letsencrypt.sh

@DesignerSkyline

revoke 正在做, 但是最近时间比较紧. 你可以看到有个 revoke 的 branch. 现在还有 bug 不能工作.

2016-02-07 18:37:03 +08:00

回复了 Livid 创建的主题 › SSL › letsencrypt.sh

@DesignerSkyline

```
pem == cer
```

直接重命名

2016-02-06 23:37:24 +08:00

回复了 Strikeactor 创建的主题 › Python › Python 的 SSL 库能把 handshake 细化到可控吗

>> ，第三个随机数产生之后客户端会用服务器证书中的公匙对它进行加密，这个加密是用的什么加密方法？

这个要看情况, 不一定是用服务器的公钥加密.

先要看协商出来的 "秘钥交换算法", 现在绝大多数都使用的是 DHE 交换算法. 试用 DHE 交换对称秘钥. 这样, 客户端就不需要用公钥加密. 只是用公钥吧最后一个报做签名.

当然也有用 RSA(或者 ECDSA) 作为 "秘钥交换算法"的, 此时服务端的证书必须是 RSA 证书或者 ECDSA, 不能是 DSA 证书. 因为 DSA 算法不能用来加密. 此时, 客户端就需要把对称秘钥用 RSA 加密发给服务端. 然后服务端和客户端就拥有相同的对称秘钥了.

从此以后, 双方就可以是用对称加密算法来传输了. 一般是 AES,3des. 这在前面也会协商对称加密算法.

通信一段时间后, 双方可能会进行对称秘钥的重协商.

2016-02-06 23:00:28 +08:00

回复了 Livid 创建的主题 › SSL › letsencrypt.sh

https://v2ex.com/t/254533#reply8

我已经支持了 dnspod 的 api 了. cloudxns 马上就来.

2016-02-04 18:58:07 +08:00

回复了 neilp 创建的主题 › 分享创造 › 世界上最短,最小,最智能的纯 Shell, Let's encrypt 客户端 le, 支持 dns 认证啦

脚本最方便，对已有系统无入侵性。可以轻易和主流服务集成。如果某项目有特殊需求除外。

2016-02-04 13:09:36 +08:00

回复了 rori 创建的主题 › 问与答 › 不同厂商 SSl 之间速度有差异？

本来握手就慢，主要是证书链太长，大于 mtu ，要来回几次传输证书握手包。增加负担。

2016-02-01 23:29:46 +08:00

回复了 sneezry 创建的主题 › 分享发现 › 80、443 端口无法使用时使用 Let’s Encrypt 签发证书

没错. 并且支持 CF 的 api

https://github.com/Neilpang/le