免费的半年 IPv4 / IPv6 和通配符域名 acme SSL 证书 HiCA

不一定要用 api 手动申请也可以
./acme.sh --issue -d \*.域名 -d 域名 --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please
配置完 TXT 记录后再跑
./acme.sh --renew -d \*.域名 -d 域名 --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please
就签发完事儿了，手动模式好像是给签发 90 天

ip 我一般都是自签用，反正也不是用来做网站

全球首家公开表示不提供且禁止代理商提供任何形式 Web UI 、 桌面 UI 等形式申请界面，还能卖得出去、收得回钱的 CA 。

这段话什么意思啊，前面申请界面看的懂，后面看不懂。

🐶https:// www1.hi.cn
❌https:// hi.cn
❌https:// www.hi.cn

小作坊的既视感。

@xxfye #3 就是你不能用他们的 API 来做一个 GUI 一键申请的那种网站，只能手动命令行申请

@xinge666 主要还是不懂”还能卖得出去、收得回钱“什么意思

"error": "registering account [] with server: directory missing newNonce endpoint"

缺失了 caddy 要求的 newNonce api
letsencrypt 是有的: https://acme-staging-v02.api.letsencrypt.org/directory

@xiangyuecn 乍一看，hi.cn 域名牛逼啊。其实 hi.cn 是我国的海南行政区划域名。amce 为二级域名。

@1423 可能我搞错了，请先忽略这条

caddy 报错似乎是因为服务只支持已被弃用的 ACME v1
letsencrypt 现在好像只提供 ACME v2 了，caddy 也只支持 v2

@xiangyuecn #4 我也这样感觉, 但是也觉得奇怪, 并且备案号是上海的

中国省级域名（海南）
https://domain.miit.gov.cn/indexd.html
https://zh.wikiversity.org/wiki/%E4%B8%AD%E5%9B%BD%E4%BA%8C%E7%BA%A7%E5%9F%9F%E5%90%8D%E5%88%86%E9%85%8D

必须 80 端口就很鸡肋了

https://publicsuffix.org/list/public_suffix_list.dat
确实 hi.cn 是保留的“cn geographic names”

是不是应该再加上这个 Slogan：
“自己的域名不用自己的 CA 的 CA”
https://www.ssllabs.com/ssltest/analyze.html?d=www1.hi.cn&s=2606%3a4700%3a3030%3a0%3a0%3a0%3aac43%3a8cf9&latest

国产的建议不要用.

我能看到用了 SSL.com 的根证书，并且 OCSP 都是自己的，但是 ssllabs 扫出来的结果是 Cloudflare 的 Baltimore Security 根。

@mercury233 80 （ http-01 ）不是 HiCA 强制的，是 ACME 标准只支持 80 端口 http 协议，不支持其他端口验证

@xiangyuecn hi.cn 是顶级域名

"issuer": "acme.hi.cn-directory", "error": "registering account [] with server: attempt 3: https://acme.hi.cn/acme/new-account: HTTP 500: {\n \"message\": \"Server Error\"\n}"}

不建议尝试，会浪费时间。

@1423 他们屏蔽了除 `acme.sh` 之外的客户端，包括 Caddy

@Zerek 试过了，`https://acme.hi.cn/directory` 不支持手动

联动下 https://www.v2ex.com/t/822401

国内不敢用，是不是有人通知下就得被注销

@stevenhawking 是的，是用 useragent 区分的，改 Caddy 一行代码就可以绕过。
curl 的话 -A "acme.sh/3.0.1 ( https://github.com/acmesh-official/acme.sh)"
然而 caddy 还是报上面的 500 ，已经放弃摆弄了。

@1423 每款客户端都有细微差异的，这家服务器应该是自己写的，没有用标准的 Boulder 来搭建，所以没有适配其他 ACME 客户端。

ip 证书没啥用，通配符证书免费的用 Let's Encrypt ，有效期 90 续签方便用着也放心

之前就有免费 6 个月的,acme.sh 的供应商之一,你 list 一下我忘了是哪个
acme.sh 应该是有四个供应商, 一个默认,一个 le,剩下两个就有一个是 6 个月还支持 wildcard

> 推荐 150 天一续，需要指定--days 参数

@1423 所以他们用的是 pki-validation 这个目录而不是 acme-challenge 是因为 v1 ？

@fredcc #22 你这是暴击


个人觉得国内的这种服务很难稳定. 上面一句话就得无理由的封, 上面一句话就得无理由的关.
好像也没有政策保护或者鼓励这种服务吧?

另外大厂的全要备案.
这种给不备案的域名发证书能活多久的确是个问题.

@realpg https://github.com/acmesh-official/acme.sh/blob/master/acme.sh#L23

Let's Encrypt / ZeroSSL / Google PKI 都是支持泛域名，但是只有 90 天

SSL.com 90 天不支持泛域名

Buypass 180 天不支持泛域名

---

之前提供国内 OCPS 的 TrustOcean 环洋诚信已经吃上免费饭了，这家能坚持多久呢

@ZeroClover #31
我记得 buypass 支持来的
不过我正式项目基本都是按域名签,不用 wildcard
只有自己玩的采用 wildcard

@ZeroClover TrustOcean 没有提供国内 OCSP 。而且经过测试，这个 HiCA 写了提供国内 OCSP ，但其实签发出来的没有提供。

所以应该是有条件提供的。

IP 证书只能用 80 来解析基本就没啥适用了。。

@Cassius

根据 CA / B Forum 的 《 Baseline Requirements Documents (SSL/TLS Server Certificates): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.4.pdf 》之定义：

1.6.1 Definitions:
Authorized Ports: One of the following ports: 80 ( http), 443 ( https), 25 (smtp), 22 (ssh).

3.2.2.4.18 Agreed‑Upon Change to Website v2
Confirming the Applicant’s control over a FQDN by validating domain control of the FQDN using the ACME HTTP Challenge method defined in Section 8.3 of RFC 8555. The following are additive requirements to RFC 8555. The CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received). The token (as defined in RFC 8555, Section 8.3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
If the CA follows redirects, the following apply:
1. Redirects MUST be initiated at the HTTP protocol layer.
a. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in RFC 7231, Section 6.4, or a 308 HTTP status code response, as defined in RFC 7538, Section 3. Redirects MUST be to the final value of the Location HTTP response header, as defined in RFC 7231, Section 7.1.2.
b. For validations performed prior to July 1, 2021, redirects MUST be the result
of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4. CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a.
2. Redirects MUST be to resource URLs with either the “http” or “https” scheme.
3. Redirects MUST be to resource URLs accessed via Authorized Ports.
Note: * For Certificates issued prior to 2021‐12‐01, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. * For Certificates issued on or after 2021‐12‐01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the
validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.

3.2.2.4.19 Agreed‑Upon Change to Website ‑ ACME
Confirming the Applicant’s control over a FQDN by validating domain control of the FQDN using the ACME HTTP Challenge method defined in Section 8.3 of RFC 8555. The following are additive requirements to RFC 8555.
The CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received).
The token (as defined in RFC 8555, Section 8.3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
If the CA follows redirects, the following apply:
1. Redirects MUST be initiated at the HTTP protocol layer.
a. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in RFC 7231, Section 6.4, or a 308 HTTP status code response, as defined in RFC 7538,
Section 3. Redirects MUST be to the final value of the Location HTTP response header, as defined in RFC 7231, Section 7.1.2.
b. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4. CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a.
2. Redirects MUST be to resource URLs with either the “http” or “https” scheme.
3. Redirects MUST be to resource URLs accessed via Authorized Ports.
Note: * For Certificates issued prior to 2021‐12‐01, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. * For Certificates issued on or after 2021‐12‐01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.

可以看到，HTTP 验证只能使用 80 端口。部分 CA 可以用 HTTPS （ 443 端口）、SMTP （ 25 端口）、SSH （ 22 端口，目前无 CA 支持）验证。

所以，IP 证书必须 80 端口验证，是他们做错了吗？

@stevenhawking
我的意思是，非 ICP 备案的都没办法用这个了。因为上海电信查 ddns 很神经，已经被 ban 过一次了。
我现在都是直接 IP 访问。
如果可以其他端口可用的话就好了。

@Cassius 用其他端口验证的话 ca 就凉了

@Cassius 这是中国局部的特殊情况，标准和合规不能随便因为局部就乱改的。否则亚洲诚信总结的 《违规被浏览器列入黑名单的 CA 、SSL 证书》（ https://blog.myssl.com/ca-blacklist/）就是下场

修复个楼上的链接：
- 违规被浏览器列入黑名单的 CA 、SSL 证书 https://blog.myssl.com/ca-blacklist/

国内体制再没有改之前不要考虑, 注销都是轻的.

@liuxyon 做一个国家的生意就要遵守一个国家的法律。如果不想做，你大可以润

这个证书有 VIP 付费功能，但是付费后，如果服务器重装，或者更换电脑就要重新收费，官方目前没有解决付费用户账号数据备份导入到新服务器的功能

@vipwuping 已经解决了，EAB 应该可用了

吃个瓜 https://github.com/acmesh-official/acme.sh/issues/4659 Notice: 官网已经打不开了

短命啊，一年不到吧，就跑路了
2023 年 6 月 9 日更新：HiCA 官网及所有证书服务已于 2023 年 6 月 6 日停止运营，所有已签发证书均会在有效期日后失效，以下所有内容仅作为历史记录。