概述:本文介绍了如何在以uhttpd为WEB后端的OpenWrt系统上申请并部署HTTPS证书以确保访问安全。
在这一过程中,我们往往需要输入密码登录WEB界面,在局域网中自然无需担心安全问题,但是,考虑外网访问场景时,同时也是为了适应Chrome、Edge等浏览器的自动密码填充功能,为密码等敏感数据的传输进行加密是很有必要的。
在浏览网页时,我们通常可以使用SSL/TLS协议加密浏览器传输的数据,简单来说就是将域名前的“HTTP://”改成“HTTPS://”,默认访问80端口改为默认访问443端口。
不过,当我们直接修改uhttpd的配置或访问443端口时会发现,浏览器提示我们“证书不受信任”,并且自动填充密码等功能也无法使用,这是因为OpenWrt上的uhttpd服务默认使用一个自签名的证书,而TLS的证书安全性来自权威的根证书机构,自己“又当运动员、又当裁判员”的行为自然不受信任。
虽然我们可以忽略证书错误或将这张证书加入操作系统信任的证书列表中规避这一问题,但使用新设备访问时仍然会遇到困难,我们应当寻求更好、更彻底、更优雅的解决办法。
因此,我们可以使用互联网上受广泛信任的根证书颁发机构为我们的域名颁发证书,但一般而言,大部分机构都是面向企业和机构颁发付费证书的,如CSDN使用的DigiCert证书如下:
但我们的网站显然不必如此大费周章,目前网上广泛使用的是Let's Encrypt的免费证书服务,Let's Encrypt使用文件验证的方式对网站的所有权进行验证,且证书有效期为3个月,由于其支持ACME自动续期,因此对于一般的服务器而言,3个月的有效期并不是什么大问题,但考虑到路由器这样的嵌入式设备,我们希望直接获取到证书文件并部署即可,无需运行额外的程序,当成“哑终端”处理。
在进行操作前,请确保你的路由器已经将自身的IP地址绑定到某个域名上,可以是IPv6,也可以是IPv4,例如使用DDNS服务或固定IP地址,通常HTTPS证书只能颁发给域名,IP一般不直接使用HTTPS证书(当然,也有例外)。
申请证书时我们可以选择国内的FreeSSL网站,使用TrustAsia颁发的证书,其有效期可达1年,且一般仅需DNS验证即可,这对于我们使用动态DNS域名的情况来说非常合适。
接下来以dynv6的DDNS域名为例,申请并部署一个https证书。
这里选择中间的“双域名(有效期:1年)”选项,并输入DDNS的域名,点击进入下一步
随后输入我们的邮箱地址,按照网站最新的使用规则,此时需要注册一个账号,这样便可以在证书到期前得到及时的邮件通知并遵守网站申请证书的最大限制。
这里推荐选择ECC类型的证书,可以在协议握手时减少开销,事实上,Chrome、Edge等现代浏览器目前也不建议使用RSA算法的证书,如下所示:
连接-已过时的连接设置
与此站点的连接已使用TLS 1.2、RSA和AES_128_GCM进行加密和身份验证。
RSA密钥交换已过时。启用基于ECDHE的密码套件。
注意:若你的uhttpd版本较旧(2016年及之前的版本),为了确保兼容性,建议仍然选择RSA证书,安全性同样具有保证。
回到正题,若没有安装或不愿意安装网站提供的离线证书管理客户端(KeyManager),则可以使用浏览器生成的方式获得密钥;验证类型则保持DNS验证不变。
网站默认使用 Web Cryptography 进行私钥和 CSR 的生成,这样就可以让私钥仅在本地产生和保存,不会经过互联网传输,尽可能的保护了你申请的证书的安全。
之后我们会下载到一个以域名命名的压缩包文件,其中包含私钥与说明,需要注意的是,对于TLS协议而言,私钥是至关重要的,一旦私钥泄漏则意味着加密失效,而证书则是可以任意传递的。
同时为了安全,网页上并不保存你的私钥,一旦丢失也就无法找回了,只能重新申请证书。
此时我们需要继续验证才能够获得最终的证书,此时网页会弹出以下验证界面,若关闭了此页面也没有关系,我们可以在右上角的“控制台”——“订单列表”中找到未完成验证的订单。
登录后打开域名的配置界面,如下:
按照要求,我们添加一条CNAME记录,这条记录可以帮助证明我们对这个子域名拥有控制权,防止冒用https证书的情况。
复制信息并填写完成后我们点击“Save”保存修改,但此时网页提示我们的输入有误,如下所示:
提示信息为“Data必须为有效的主机名”,这是为何呢?其实,这并不是我们填写有误,而是dynv6网站的问题,我们可以先删除“Data”字段中的数据,随意输入一些值,例如“123”等等,点击保存即可。
可以看到已经保存成功,这样的显示符合CNAME的“重定向”作用。
接下来点击“edit”,将“Data”字段修改为我们需要的域名。
此时便可以正常保存了。
确认无误后即可在订单页进行验证。
此时,我们会发现显示结果为“不匹配 (CNAME 值不匹配)”。
当然,这并不是网站出了问题或更改没有同步,而是涉及到域名的结构和解析方式。
具体到这个问题上来说:我们添加CNAME记录时在“Data”字段填写的是形如“aa.bb.cc.xx.com”的记录,这会导致解析结果有误,我们应当在数据的最后添加一个英文句号,即“.”,构成“aa.bb.cc.xx.com.”的形式即可,这样便可以解析成功。
对于这个问题,我们可以展开讨论一下(注意:此部分内容与文章主题无关,要继续完成部署可以跳过本段)
一般地,我们在浏览器中输入的网址格式通常都是形如“www.abc.com”这样的地址,而其中的“abc.com”即为一个域名,进一步地,“abc.”表示机构的名称;“com”则是一个顶级域名,表示商业公司(company);最开始的“www.”则是一个二级域名,代表着WWW(World Wide Web,万维网)服务。
通过观察我们可以发现,一个完整网址的每一段后都使用一个英文句点“.”相互分隔,但最后一段除外。
事实上,最后一段隐含了一个分隔符,由于其总处于最后一个位置,浏览器可以自动识别到并发出DNS解析请求,例如上面的网址可以写作“www.abc.com.”,这也是完全能够访问的,但浏览器会自动帮我们去除最后的“.”。
回到dynv6的CNAME记录问题,事实上,如果不添加最后的“.”,那么这个值将被自动理解为是一个子域名…
之后回到订单页面,点击“验证”即可(可能会出现报错的情况,多次点击后即可完成)。
点击“获取”即可下载证书,得到的压缩包文件中有两个文件,分别是证书链文件(.pem)和对应的私钥文件(.key),接下来我们把它们部署到路由器上。(提示:要在Windows上查看这张证书,可以将.pem文件修改为.crt文件,双击打开即可)
可以看到,这张证书受操作系统信任,有效期自申请通过之日起为1年。
同时,这张证书所依赖的根证书有效期更长,达到了25年之久,因此,大多数支持TLS协议的设备都会内置这家机构的根证书,确保了广泛的兼容性。
接下来我们将证书上传到路由器中。
打开文件传输工具WinSCP,登录到路由器上,将证书重命名后复制到路由器中。
参考此前的教程,我们直接定位到uhttpd的配置文件,其保存于
/etc/config/uhttpd
路径下。
我们直接修改这两行配置项,将其设置为证书与私钥的保存路径。
注意:不要将证书与私钥直接放置在web目录(/www)下,否则可能有泄露私钥的风险。
修改完成之后还需要重启uhttpd服务才可以重新加载我们的配置文件与证书,打开putty或其它SSH客户端,登录到路由器,输入
/etc/init.d/uhttpd restart
并回车即可。
接下来刷新网页即可看到我们的网站已经受到浏览器的信任,可以安全访问了。
–END–
原文链接:https://blog.csdn.net/weixin_43593122/article/details/128749677?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522168525635616800213086355%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=168525635616800213086355&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-24-128749677-null-null.268%5Ev1%5Econtrol&utm_term=NAS%E3%80%81%E7%BE%A4%E6%99%96%E3%80%81%E9%98%BF%E9%87%8C%E4%BA%91%E3%80%81%E5%9F%9F%E5%90%8D%E8%A7%A3%E6%9E%90%E3%80%81%E5%86%85%E7%BD%91%E7%A9%BF%E9%80%8F%E3%80%81ipv6%E3%80%81ddns%E3%80%81%E8%BD%BB%E9%87%8F%E7%BA%A7%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8%E3%80%81%E9%93%81%E5%A8%81%E9%A9%AC%E3%80%81%E5%A8%81%E8%81%94%E9%80%9A%E3%80%81DSM%E3%80%81DSM6.0%E3%80%81%E7%BE%A4%E6%99%96nas%E3%80%81%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8%E3%80%81%E8%9C%97%E7%89%9B%E6%98%9F%E9%99%85%E3%80%81%E9%BB%91%E7%BE%A4%E6%99%96%E3%80%81docker%E3%80%81%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F%E3%80%81%E5%9F%9F%E5%90%8D%E6%B3%A8%E5%86%8C%E3%80%81%E5%AE%9D%E5%A1%94%E3%80%81%E5%8F%8D%E5%90%91%E4%BB%A3%E7%90%86%E3%80%81nginx%E3%80%81frp%E3%80%81%E5%8A%A8%E6%80%81%E5%9F%9F%E5%90%8D%E8%A7%A3%E6%9E%90