SSL

记录一起Caddy由于无法绑定80、443端口导致的服务启动失败事故

常规方法安装完Caddy,写好Caddyfile和systemd服务配置文件后sudo systemctl start caddy,结果发现在获取证书时失败,导致整个服务启动失败:

failed to obtain certificate: acme: Error -> One or more domains had a problem:

Mar 05 09:55:48 instance-2 caddy[1846]: [ mydomain.example.com ] [ mydomain.example.com ] acme: error presenting token: presenting with standard provider server: could not start HTTPS server for challenge -> listen tcp :443: bind: permission denied

开始以为是 setcap 的问题,但是检查过后,发现安装时的设置没问题:

getcap /usr/local/bin/caddy
/usr/local/bin/caddy = cap_net_bind_service+ep

而且直接命令行启动也没有问题,那么看来应该是systemd服务配置中的问题,一番搜索后发现了这个:Caddy won’t start – Could not start HTTP server for challenge -> listen tcp :80: bind: permission denied ,参考问题中的解决方法,修改caddy.service配置为:

Continue reading…

Wireshark拦截并分析https协议数据包(浏览器和Java程序)

https数据包拦截解析这个事之前也做过,不过是借助一个叫 fiddler 的中间代理软件实现的,https协议包其实是在http包之上加了一层ssl加密,所以直接用Wireshark的话只能看到加密后的TCP包内容,没法拿来分析http请求响应的内容。最近发现其实对于浏览器(Chrome,Firefox,其它未测),可以在Windows系统的环境变量中加入:

Continue reading…

CentOS 7下自编译、打包RPM最新版Apache2 (httpd 2.4.37) 并开启HTTP/2

之前一直没什么时间研究新东西,博客上写的也都是些没啥滋味的东西,今天记录的这个应该能算是有些滋味的吧,不过,在正文之前,先写点铺垫,为啥现在研究起http 2.0了?这个h2吧,其实很早以前就听说过,各种好吧就是,但之前一直都有一种还很理论还很遥远的感觉,直到最近研究Google GRPC的Web实现gRPC-Web(有兴趣的话,传送门在这里:https://grpc.io/docs/quickstart/web.html)时,发现其中用到了一个叫envoy的转发代理服务器(https://www.envoyproxy.io/)来实现gRPC传输层需要的h2协议,突然感觉h2要开始普及了,查了下资料,发现h2的server push设计很有吸引力(其间还找到个这个网站:https://http2.akamai.com/demo,直观的演示了http 1.1和2.0的差距),于是乎萌生了测试下h2用在普通网站服务器的想法。

一开始还觉得现在是不是主流Web服务器都支持http2了,一查发现本博用的lighttpd还没有加入http2的支持,而apache和nginx已经有稳定支持版本了,又搜索了下网上的评论,发现还是Apache跟的比较紧,所以就从老朋友Apache入手尝鲜吧。

我的测试环境是装在虚拟机里的CentOS Linux release 7.5.1804 (Core),直接yum安装httpd的话是2.4.6-80.el7.centos.1 这个版本,而Apache是从 2.4.17 才开始支持mod_http2正式支持h2的,残念之后习惯性的找各种第三方rpm源,看是否有能直接撞的2.4.17以上版本,结果发现虽然是有,但是很少,而且也不是特别新的版本(另外这里https://www.mf8.biz/apache-httpd-%E5%BC%80%E5%90%AF-https-%E5%92%8C-http2/也提到”截止发文切仍受支持的 RHEL、CentOS 5、6、7 均不提供 Apache Httpd(apache2) ≥ 2.4.17 和 OpenSSL ≥ 1.0.2 的支持,也没有提供支持的第三放软件源支持。”),于是就想不行就自己直接拿源码装吧。其实,如果只是拿源码装的话应该是挺简单的,要啥编啥就得了,不过我这还有个需求就是想把编译好的新版apache方便的装到远端VPS上测试,当然VPS也是CentOS的,所以就变成了不止要自编译还要打包RPM了…

Continue reading…

使用StartSSL(Let’s Encrypt)的免费SSL证书为Windows远程桌面RDS服务指定受信任的证书

首先,简单说明一下这个大标题所要解决的问题,就是这个:
QQ截图20150807221006
经常使用Windows远程桌面(AKA: mstsc3389RDP…)的朋友对这个截图的画面一定不会感到陌生,记不清从哪个版本开始的,迈克尔索芙特公司为这个远程桌面服务加入了SSL (TLS 1.0)加密功能,而且是默认开启的,这就导致了这个连接时需要“验明正身”的过程。而正式可信的SSL证书都是需要缴纳一定的“保护费”来获得的,安全级别越高,费用也就越高,所以这里默认启用的加密证书是以自签名的方式颁发的,因此自然会弹出这个不可信的警告了。
对于一般用户而言,这个不可信的证书其实也没什么大不了的,无视它,在mstsc里关闭服务器身份验证失败警告,信任它,直接添加自己为可信的证书颁发机构,又或者直接在组策略里关掉加密,都可以直接pass掉这个问题,但如果是正规应用的话(或者是像我这样有强迫症的一般用户),当然还是要加上正规身份证的好了。
这里介绍的方法就是如何用当下提供免费SSL证书的StartSSL.com,为Windows RDS(主要针对非服务器版操作系统)添加一个受信的正规远程桌面RDS服务加密证书:
Continue reading…

使用StartSSL免费SSL证书为SubversionEdge添加受信任的https访问

以前搭建SVN服务器时一直是用纯手动添加svnserve服务命令行的方式做的,最近发现CollabNet推出了一款叫做SubversionEdge的整合SVN服务器一键安装程序,试了一下还是很方便的,自带一个web方式的管理界面,查日志啊,创建资源库之类的操作都可以以可视化的方式进行,很是方便!

SubversionEdge默认安装的是http方式的SVN访问方式,当然也包含https方式访问,为了提高网络传输安全性,准备尝试一下带SSL的http访问方式,在设置中勾上https访问方式直接重启就可以了,但是浏览器访问的时候会提示SSL证书错误,这是因为SubversionEdge的https使用的是自带默认的SSL证书,域名和自己架设的对不上号,当然就证书错误了,下面要做的就是申请一个正式的SSL证书修正这个错误!

Continue reading…