Max Koshel
Max Koshel

Reputation: 177

How to generate self-signed certificate for IP address (without domain name)?

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

Upvotes: 3

Views: 2375

Answers (1)

Dawid Kruk
Dawid Kruk

Reputation: 9877

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:

Upvotes: 1

Related Questions