如何为IP地址(不带域名)生成自签名证书? [英] How to generate self-signed certificate for IP address (without domain name)?

问题描述

我在谷歌云 k8s 集群中有一个私有 docker 注册表，可以只能通过 IP 访问.

我尝试做的事情:

1. 编写脚本以生成自签名证书.
2. 在 docker 注册表端使用生成的自签名客户端密钥和证书.
3. 将每个 k8s 节点上的 CA 证书放到 /etc/ssl/certs/registry-proxy-ca.pem 并运行 update-ca-certificates &&systemctl 重启 docker .

我希望当 k8s 节点尝试创建 pod 并从 docker 注册表中提取图像时，客户端的自签名证书将得到批准.

但我还是有错误:

x509:由未知权威签署的证书

谁能帮我理解我做错了什么?我的脚本:

IP=10.3.240.100LIFESPAN_DAYS=35600CERTS_DIR=platform/cert-customizations/certsCA_KEY=$CERTS_DIR/registry-proxy-ca.keyCA_PEM=$CERTS_DIR/registry-proxy-ca.pemOPENSSL_CONFIG=$CERTS_DIR/openssl.cnfREGISTRY_CERT_DIR=platform/registry-proxy/certsREGISTRY_CERT_KEY=$REGISTRY_CERT_DIR/tls.keyREGISTRY_CERT=$REGISTRY_CERT_DIR/tls.crtREGISTRY_CSR=$REGISTRY_CERT_DIR/registry-proxy.csrREGISTRY_EXTFILE=$REGISTRY_CERT_DIR/extfile.cnfecho subjectAltName = IP:$IP >$REGISTRY_EXTFILEcat >>$OPENSSL_CONFIG <<EOL[要求]default_bits = 2048req_extensions = req_extx509_extensions = x509_extstring_mask = utf8only尊贵姓名 = 主题[ 主题 ]# 为简单起见，我将跳过内容.# ...[ x509_ext ]主题密钥标识符 = 哈希authorityKeyIdentifier = keyid,issuer基本约束 = CA:FALSEkeyUsage = digitalSignature, keyEnciphermentsubjectAltName = @alternate_names[req_ext]主题密钥标识符 = 哈希基本约束 = CA:FALSEkeyUsage = digitalSignature, keyEnciphermentsubjectAltName = @alternate_names[备用名称]IP.1 = ${IP}停产# 私钥openssl genrsa -out $CA_KEY 2048# 公共根 CAopenssl req -subj/CN=Nerdia Root CA"；-x509 -new -nodes -key $CA_KEY -sha256 -days $LIFESPAN_DAYS -out $CA_PEM# 为 docker 注册表创建证书openssl genrsa -out $REGISTRY_CERT_KEY 2048openssl req -subj "/CN=${IP}";-config $OPENSSL_CONFIG -new -key $REGISTRY_CERT_KEY -out $REGISTRY_CSRopenssl x509 -req -in $REGISTRY_CSR -CA $CA_PEM -CAkey $CA_KEY -CAcreateserial -out $REGISTRY_CERT -days $LIFESPAN_DAYS -sha256 -extfile $REGISTRY_EXTFILE

解决方案

此特定问题中的问题与 GKE 正在使用的 CRI 相关.

引用稍微修改的官方文档(部分):

<块引用>

<头>

操作系统	节点图像	说明
容器优化操作系统	Container-Optimized OS with Containerd (cos_containerd)	cos_containerd 镜像使用 Containerd 作为直接与 Kubernetes 集成的容器运行时.有关详细信息，请参阅使用 Containerd 映像
	容器优化操作系统与 Docker (cos)	cos 镜像使用 Docker 容器运行时

-- Cloud.google.com:Kubernetes Engine:文档:概念:节点图像:可用节点图像

具体图片:

• gke-1199-gke1400-cos-85-13310-1209-12-v210407-c-pre

使用 containerd 作为 CRI 而不是 Docker(请参阅 -c-).因此: $ systemctl restart docker 没有给出预期的结果.解决方案是将 systemctl restart ... 中的 docker 替换为 containerd.

您可以通过以下任一方式检查您正在使用的 CRI:

• $ kubectl get nodes --output wide
• 签入 Cloud Console(网页界面)

---

附注！

<块引用>

在 Containerd 节点上运行 Docker 命令

虽然 Docker 二进制文件目前在 Containerd 节点上可用，但我们不建议您在迁移到 Containerd 后使用它.Docker 不管理 Kubernetes 在 Containerd 节点上运行的容器，因此您不能使用它来查看或使用 Docker 命令或 Docker API 与正在运行的 Kubernetes 容器交互.

警告:Docker 无法查看或访问由 Kubernetes 管理的容器或图像.您的应用程序不应直接与 Docker 交互.对于一般故障排除或调试，请改用 crictl.

-- Cloud.google.com:Kubernetes Engine:文档:概念:使用 containerd:迁移

---

其他资源:

• Cloud.google.com:Kubernetes 引擎:文档: 概念:使用 containerd

I have a private docker registry in a google cloud k8s cluster that could be accessed only by IP.

What I've tried to do:

1. Wrote script to generate self-signed certificate.
2. Use generated self-signed client key and certificate on the docker registry side.
3. Put CA certificate on each k8s node to /etc/ssl/certs/registry-proxy-ca.pem and run update-ca-certificates && systemctl restart docker.

I expect that client self-signed certificates will be approved from the k8s nodes when they tries to create pods and pull the images from the docker registry.

But I still have an error:

x509: certificate signed by unknown authority

Could anybody help me to understand what I did incorrectly? My script:

IP=10.3.240.100

LIFESPAN_DAYS=35600

CERTS_DIR=platform/cert-customizations/certs
CA_KEY=$CERTS_DIR/registry-proxy-ca.key
CA_PEM=$CERTS_DIR/registry-proxy-ca.pem
OPENSSL_CONFIG=$CERTS_DIR/openssl.cnf

REGISTRY_CERT_DIR=platform/registry-proxy/certs
REGISTRY_CERT_KEY=$REGISTRY_CERT_DIR/tls.key
REGISTRY_CERT=$REGISTRY_CERT_DIR/tls.crt
REGISTRY_CSR=$REGISTRY_CERT_DIR/registry-proxy.csr
REGISTRY_EXTFILE=$REGISTRY_CERT_DIR/extfile.cnf

echo subjectAltName = IP:$IP > $REGISTRY_EXTFILE

cat >>$OPENSSL_CONFIG <<EOL
[ req ]
default_bits        = 2048
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only
distinguished_name  = subject

[ subject ]

# For simplicity, I will skip over the contents.
# ...

[ x509_ext ]

subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid,issuer

basicConstraints        = CA:FALSE
keyUsage                = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names

[ req_ext ]

subjectKeyIdentifier    = hash

basicConstraints        = CA:FALSE
keyUsage                = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names

[ alternate_names ]

IP.1 = ${IP}
EOL

# Private key
openssl genrsa -out $CA_KEY 2048

# Public root CA
openssl req -subj "/CN=Nerdia Root CA" -x509 -new -nodes -key $CA_KEY -sha256 -days $LIFESPAN_DAYS -out $CA_PEM

# Create a cert for docker registry
openssl genrsa -out $REGISTRY_CERT_KEY 2048
openssl req -subj "/CN=${IP}" -config $OPENSSL_CONFIG -new -key $REGISTRY_CERT_KEY -out $REGISTRY_CSR
openssl x509 -req -in $REGISTRY_CSR -CA $CA_PEM -CAkey $CA_KEY -CAcreateserial -out $REGISTRY_CERT -days $LIFESPAN_DAYS -sha256 -extfile $REGISTRY_EXTFILE

解决方案

The issue in this particular question was related to the CRI that the GKE is using.

Citing slightly modified official documentation (part of it):

OS	Node images	Description
Container-Optimized OS	Container-Optimized OS with Containerd (cos_containerd)	The cos_containerd image uses Containerd as the container runtime directly integrated with Kubernetes. For more information, see Using Containerd images
	Container-Optimized OS with Docker (cos)	The cos image uses the Docker container runtime

-- Cloud.google.com: Kubernetes Engine: Docs: Concepts: Node images: Available Node images

The specific image:

• gke-1199-gke1400-cos-85-13310-1209-12-v210407-c-pre

is using containerd as CRI and not Docker (see the -c-). Hence the: $ systemctl restart docker did not give the expected result. The solution was to replace the docker to containerd in the systemctl restart ....

You can check which CRI you are using by either running:

• $ kubectl get nodes --output wide
• checking in the Cloud Console (Web UI)

---

A side note!

Running Docker commands on Containerd nodes

While the Docker binary is currently available on Containerd nodes, we do not recommend using it after you migrate to Containerd. Docker does not manage the containers Kubernetes runs on Containerd nodes, thus you cannot use it to view or interact with running Kubernetes containers using Docker commands or the Docker API.

Warning: Docker cannot view or access containers or images managed by Kubernetes. Your applications should not interact with Docker directly. For general troubleshooting or debugging, use crictl instead.

-- Cloud.google.com: Kubernetes Engine: Docs: Concepts: Using containerd: Migrating

---

Additional resources:

• Cloud.google.com: Kubernetes Engine: Docs: Concepts: Using containerd

这篇关于如何为IP地址(不带域名)生成自签名证书?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！