FYI: gitea certificate should be signed by a CA authority <-> backstage

[cmoulliard]

FYI

The gitea certificate used by idpbuilder should be signed by a CA authority (let's encrypt, etc) otherwise backstage won't accept to create a project on gitea repository

[cmoulliard]

I tested different scenario without success except using by example a valid domain and godaddy: gitea.snowdrop.devand the help of Let's encrypt + cert manager on k8s

Otherwise, when I use locally gitea + the following tools to generate the certificate, that failed as backstage reported errors. See hereafter:

minica or mkcert tools DO NOT WORK as backstage when creating the git repo returns: unable to verify the first certificate using localhost:3333

openssl DO NOT WORK too as we got also: unable to verify the first certificate

If we try to add the CA root + localhost crt to a chain crt file, then we got another error: self-signed certificate in certificate chain

That could work using certbot if you have a domain !

source ~/.pyvirt/bin/activate
pip install certbot==2.6.0
pip install -U certbot-dns-godaddy==2.6.0
sudo certbot certonly -v --authenticator dns-godaddy --dns-godaddy-propagation-seconds 900 --dns-godaddy-credentials godaddy.ini --keep-until-expiring --non-interactive --expand --server https://acme-v02.api.letsencrypt.org/directory -d 'snowdrop.dev'

Waiting 900 seconds for DNS changes to propagate
Waiting for verification...
Cleaning up challenges

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/snowdrop.dev/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/snowdrop.dev/privkey.pem
This certificate expires on 2024-04-02.
These files will be updated when the certificate renews.

NEXT STEPS:
- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.

Can you help me ? @nabuskey

[jessesanford]

@cmoulliard when you tried the following

If we try to add the CA root + localhost crt to a chain crt file, then we got another error: self-signed certificate in certificate chain

what commands did you use? I assume you were attempting to add the certs into the bundle used by the backstage container correct?

[cmoulliard]

what commands did you use?

I was simply concaiting the different pem into one called: fullchain (cat file1 file2 > fullchain.pem)

[cmoulliard]

into the bundle used by the backstage container correct?

I'm not using here a backstage container/pod but running backstage using simply (yarn dev, etc)

[cmoulliard]

I found a trick using such env var export NODE_TLS_REJECT_UNAUTHORIZED=0 to be set before to launch the backend

yarn start-backend --config ../../app-config.yaml --config ../../app-config.local.yaml

then I can launch the gitea server where ssl is enabled using https://localhost:3333/

[server]
PROTOCOL = https
HTTP_PORT = 3333

CERT_FILE = pki/openssl/localhost.pem
KEY_FILE = pki/openssl/localhost-key.pem

The openssl crt file looks like this one

-----BEGIN CERTIFICATE-----
MIIFcDCCA1igAwIBAgIUMjagEoGTaNdiJpPS/pfY8YBttkEwDQYJKoZIhvcNAQEN
BQAwIzELMAkGA1UEBhMCQkUxFDASBgNVBAMMC1Nub3dkcm9wLUNBMB4XDTI0MDEw
MzE2NTIyMFoXDTI1MDEwMjE2NTIyMFowSTELMAkGA1UEBhMCQkUxEzARBgNVBAcM
ClNpbGVucmlldXgxETAPBgNVBAoMCFNub3dkcm9wMRIwEAYDVQQDDAlsb2NhbGhv
c3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDvh2MtsrtcNrTcPL3v
vnN+fMdFAriUKwAZLGaV8b43QXL3TZoMBs/8Fh1e3Lzl9IMOOQLd7FVJgOtEaW7h
E3UbZYFCl/uMznl6td+m7Mm1DzlpG0srzQPD0Tz5tmYHR63E2bRaGcqkcOi0vwdH
izWl4fmtAWrk6kSkoB3SkfIQUCO+LOy8xIMDPaqYyy4TISqO/4FXNenAGaQCdv7U
DqSnLb5ICDXGhUYmIK4OwuQd5bdAvHEibDoMK7dB6wLRVyzqZUDmq6/ryfiJQwx2
1YwLBVqi+Z97gc49tFD7L0XkpvguVhh49IQNlGAdjbXBSO9VmtleLtvpOSGVnrzx
MN0ZFLyvIpCDYDdDYWmBpCTm1y4V7a4X6d97UhJOnuL7HH3gaRDxAdk4NBn/tkpc
c2QhxR/JrWXFGUVCySzZMsx2eprW8X+voeUgsHBkRe929w+rRiN98Ua3lZp5ElJg
M0I7PDpn25rW9MVLC3LkKUiIUrgUhFpSrxMEV1r7BoyCaNB65qqu7TBwAPeCOuHh
wlVk4etzvsg/sOMTxZOfu8ee9Lr0pbapVeoEnQCozrfQ2XKsnk5VOSxSGMyCXo6b
oIN14TTr7PUslJp5Ngf1Kx38U9NMbmb1G7gFVAUq5IE8Hk1xdeztYgv/4aRgpLdh
0VZpCQC0sSCRoxA0Pb802TD5qwIDAQABo3YwdDAfBgNVHSMEGDAWgBToNFXRMFUn
V4yoRO57GKFKX5buIDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIE8DAaBgNVHREEEzAR
gglsb2NhbGhvc3SHBH8AAAEwHQYDVR0OBBYEFENUH8tym2Uzuzvlj/RcyurUzNNx
MA0GCSqGSIb3DQEBDQUAA4ICAQAmcJqGfK1/48z7brCFi6LD4bgkv3PCyzmM+rXz
PLk4CwjxwLGrizTl8fw+Cak66dGs7WzklBFh+9bzDovxGhffX/icBFfenDg/EpLk
1QlHytuJOup9fa+6qstZubJj+ncaSeYBYKIuoKBtyTz3oS1VPIkoykpvc0/Vb4n0
KUpRtuDFCFDJ0F6X4Ehpmdr+DZ6pskxatSytdhhLikqNLNGpDScJKJV9D9iNIHoY
A030cAOgF53IqTJrJV4tB3Xshs1zuw0/Wdp50guBf26Uh2dENSC10ILSdFvEpvvH
hDk0ACDtAQh2rCbCVZhnGKlRq3jg3ohw4nwghyygs926fIVI8yAX+ih4VXFTFFxT
qKYHcll/UAFGS9soDxTPJYHEJF1nWC5LUDRKn1ehPemlYbsskq8DC2Uqw7VzdWNj
bZVy1fPDPquqjJwKjc76Tr6hH64W/IJVNbwo5gNaZQYhAWbWJV1t1y+sEd1nFwOF
8WyFZMy9Eeu/W232ymVzbXmo5u0pfHvfEvRkOWbrqWeghpr4MtqXVRETQgQhWvkS
QAUv3byBg2VJj9UUlQfHMAHcqR4ZvCZF4eZMNzv3R8T90tK1TKT03sFQCJFFvNMO
u9g5TRMDFtqk/Um1CcTzINcG0O6oZZSIysVJGf8h0OLBLZdDFULL70XIAbYM2qGv
INfOYA==
-----END CERTIFICATE-----

Then backstage do not complain and can create a git repository :-)

[nabuskey]

I would recommend against using the NODE_TLS_REJECT_UNAUTHORIZED env var because it affects all fetch calls. I would set it in fetch params so that TLS certs are not verified for certain calls only.

[jessesanford]

Can we use NODE_EXTRA_CA_CERTS and point it to your fullchain.pem? https://nodejs.org/api/cli.html#node_extra_ca_certsfile

[jessesanford]

Alternatively, we could use the --use-openssl-ca node option and then add the root and intermediate certs to the ca bundle in the host os.

[cmoulliard]

Can we use NODE_EXTRA_CA_CERTS and point it to your fullchain.pem? https://nodejs.org/api/cli.html#node_extra_ca_certsfile

This option is working :-) @jessesanford

[cmoulliard]

--use-openssl-ca

I don t think that we should use such an option as we will run gitea as kubernetes's pod. A better approach will be to use the Cert Manager able to generate a selfsigned certificate https://cert-manager.io/docs/configuration/selfsigned/#bootstrapping-ca-issuers (CA crt can be used from a secret) and distribute the bundle using: https://cert-manager.io/docs/trust/trust-manager/

Note: I developed a project for java applications and cert manager + pkcs12 - https://github.com/snowdrop/pki?tab=readme-ov-file#create-a-pkcs12-using-cert-manager

[cmoulliard]

For local usage of the gitea server (= when running standalone and not as k8s's pod), we can create the certificate using simply the gitea client command => gitea cert --host localhost -ca
It is still needed nevertheless to pass set this env var for backstage

export NODE_EXTRA_CA_CERTS=/path/where/gitea/generated/certificate/cert.pem

To control everything like key size, algorithm, Subject, CN, AltNames, etc, then using openssl do the job too ;-)

1. Generate a private key and CA certificate

mkdir openssl; cd openssl
openssl req -x509 -nodes -new -sha512 \
  -days 365 \
  -newkey rsa:4096 \
  -keyout ca.key \
  -out ca.crt \
  -subj "/C=BE/CN=Snowdrop-CA"

3. Generate a x509 v3 extension file:

cat > v3.ext <<-EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names 
[alt_names]
# Local hosts
DNS.1 = localhost
IP.1 = 127.0.0.1
EOF

5. Generate a private key and certificate sign request (CSR) for localhost

openssl req -new -nodes -newkey rsa:4096 \
 -keyout localhost.key \
 -out localhost.csr \
 -subj "/C=BE/L=Silenrieux/O=Snowdrop/CN=localhost"

6. Generate a certificate signed using the CA cert using the CSR:

openssl x509 -req -sha512 -days 365 \
  -extfile v3.ext \
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -in localhost.csr \
  -out localhost.crt