我踩了哪些坑？

这一步，我愿踩之踩坑的第一步，正所谓万事开头难，但我没有想到，第一步就这么难，真的就从入门到放弃。

官方文档上就短短的几行话，但这几行话让我踩了两个大坑。

第一个坑

第一个坑就是 OpenSSL居然没有+addext这个参数！！！🤯 但我此时的脑回路，居然是不要这个参数。。。。然后就一直出各种各样的问题。

后来查资料才发现，+addext是OpenSSL 1.1.1以上的版本才支持，而我的机器的OpenSSL是1.0.2。

解决这个问题也非常简单，就是升级OpenSSL即可，大家可以参考一下这篇博客：OpenSSL升级

第二个坑

相比较第一个坑，第二个坑可就比较难了。

完完全全按照官方文档上的步骤进行操作，但是就一直给我报错

查了超级多的资料都没有解决，气到💥

后来在身边同学的提醒下，可以通过一些查看证书的网站来查看证书的具体内容，然后我是用的这个网站来查看的：myssl.com/cert_decode…

查看了证书的内容之后，发现可能🤔是SAN设置的有问题。这里可以大概说一下什么是SAN——

SAN(Subject Alternative Name) 是 SSL 标准 x509 中定义的一个扩展。使用了 SAN 字段的 SSL 证书，可以扩展此证书支持的域名，使得一个证书可以支持多个不同域名的解析。

我简单理解了一下，SAN大致功能就是将你的证书和你的域名或者IP绑定，比如说在官方文档提供的案例中就是和域名相绑定，但在我的情境里，我的es是没有域名的，只有一个LoadBalancer IP来访问，因此我按照官方文档那样来生成证书就无法通过LoadBalancerIp来访问es集群服务了。

然后，重新修改了一下OpenSSL生成证书的命令：

openssl req -x509 -sha256 -nodes -newkey rsa:4096 -days 3650 -subj "/CN=es-main-lbsvc" -addext "subjectAltName=IP:172.17.31.8" -keyout tls.key -out tls.crt

eck-operator增加自定义证书实践步骤

1. 通过OpenSSL生成证书

openssl req -x509 -sha256 -nodes -newkey rsa:4096 -days 3650 -subj "/CN=es-main-lbsvc" -addext "subjectAltName=IP:172.17.31.8" -keyout tls.key -out tls.crt

2. 通过指定证书生成secret

ca.crt: CA 证书 (可选如果 tls.crt 是被知名CA签发的).
tls.crt: 证书
tls.key: 证书链中的根证书的私钥

kubectl create secret generic es-main-es-cert -n kube-system --from-file=ca.crt=tls.crt --from-file=tls.crt=tls.crt --from-file=tls.key=tls.key

设置静态IP

在es-main中增加如下字段：

spec:
  http:
    service:
      spec:
        type: LoadBalancer
    tls:
      selfSignedCertificate:
        subjectAltNames:
        - ip: 172.17.31.19

绑定secret

在es-main中绑定step2中创建的secret

spec:
  http:
    tls:
      certificate:
        secretName: es-main-es-cert

执行完以上四步之后，就可以来验证一下了

反思

其实这个需求前前后后，磨磨蹭蹭也干了好久了，结果一直卡在验证官方文档的demo这一步，真的过分丢脸了。然后是这个需求提上了规划日程，我才全力投入去做。

在这个过程中，因为自己怕麻烦，不愿意升级OpenSSL，导致在+addext参数这一步卡了好久，也走了很多弯路，所以说，人有时候真的不能偷懒。

其次是在做需求时一直是急于有一个产出，而没有关注底层原理，如果我这次能够早一点深究一下SAN和证书以及域名，IP的关系，也不会卡这么久了。

eck-operator增加自定义证书——关于我被官方文档坑了这件事