Closed mmorhun closed 4 years ago
from Chrome 79 release notes https://support.google.com/chrome/a/answer/7679408
Directly trusted end-entity (leaf) certificates: The built-in verifier does not support directly marking server certificates as trusted; certificates must be issued by a CA that is trusted.
maybe related
@azatsarynnyy thank you for your investigation! But we already generate CA certificate and certificate request and then create server certificates and do import CA certificate into browser... Should be something else...
Hello! Any insight on how to resolve/workaround?
Also, seems working on Chrome for Windows 10, but not under Ubuntu 18.04 Desktop.
@ultrafab you still may add an exception via developer options in Google Chrome or just use Firefox.
@ultrafab you still may add an exception via developer options in Google Chrome or just use Firefox.
Thanks, i'm using Firefox right now. But could you please provide the method to add the exception via developer tools in Chrome, cause i've looking but i'm unable to find. Thanks!
In Chrome you can add the certificate under settings. Go to Settings -> Advanced -> Privacy and security -> Manage certificates. When the window pops up, navigate to the "Authorities" tab, and click import. Select the certificate file and check all three boxes when prompted. After this you should have no issue using Che in Chrome.
@ultrafab one may run Google Chrome with --ignore-certificate-errors
flag (close all Chrome windows before). This is good to try something you know out, but is not suitable for everyday usage.
The problem is in wrong keyUsage
values in the end certificate.
Here is the correct steps to generate self-signed certificate (change DOMAIN
and OPENSSL_CNF
according to your needs):
CA_CN=eclipse-che-signer
DOMAIN="*.$(minikube ip).nip.io"
OPENSSL_CNF=/etc/pki/tls/openssl.cnf
# Generate CA key
openssl genrsa -out ca.key 4096
# Generate root CA certificate
openssl req -x509 -new -nodes -key ca.key -sha256 -days 1024 -out ca.crt -subj /CN=${CA_CN} -reqexts SAN -extensions SAN -config <(cat $OPENSSL_CNF <(printf '[SAN]\nbasicConstraints=critical, CA:TRUE\nkeyUsage=keyCertSign, cRLSign, digitalSignature'))
# Generate server key
openssl genrsa -out domain.key 2048
# Create certificate request for the domain
openssl req -new -sha256 -key domain.key -subj "/C=UA/ST=CK/O=Local Eclipse Che/CN=${DOMAIN}" -reqexts SAN -config <(cat $OPENSSL_CNF <(printf "\n[SAN]\nsubjectAltName=DNS:${DOMAIN}\nbasicConstraints=critical, CA:FALSE\nkeyUsage=digitalSignature, keyEncipherment, keyAgreement, dataEncipherment\nextendedKeyUsage=serverAuth")) -out domain.csr
# Create certificate for the domain
openssl x509 -req -extfile <(printf "subjectAltName=DNS:${DOMAIN}\nbasicConstraints=critical, CA:FALSE\nkeyUsage=digitalSignature, keyEncipherment, keyAgreement, dataEncipherment\nextendedKeyUsage=serverAuth") -days 365 -in domain.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out domain.crt
The problem is in wrong
keyUsage
values in the end certificate.
Confirmed. Working correctly with the info provided.
Instructions in Che docs have been updated.
Describe the bug
When generate a self-signed certificate according to Che docs and deploy Eclipse Che with it and then import the certificate into Google Chrome browser it still doesn't trust the certificate and even doesn't provide a button to add it into exceptions (however it is still possible via some settings).
However Firefox, curl and openssl accepts the certificate as valid one (with added CA certificate).
Che version
nightly
Steps to reproduce
Deploy Eclipse Che with self-signed certificate according to Che docs and try to open dashboard (or any other Che endpoint, like Keycloak).
Expected behaviour
All browsers accept the certificate
Runtime
Minikube
Installation method
chectl
Additional context
It used to work some time ago. Probably newer version of Chrome has some additional requirements to the certificate. Also, the generated certificate is ok for Firefox, curl and openssl (at least).