Step 1 – create a private key for my own root CA.

openssl genrsa -out ca.key 2048

Step 2 – create a root CA certificate file

openssl req -x509 -new -nodes -key ca.key -sha256 -days 1024 -out ca.crt

Step 3 – create a private key for to be later used to create a tls SAN certificate

openssl genrsa -out example.com.key 2048

Step 4 - create an V3 extension config file with SAN DNS names (oats.conf)

[ req ]

default_bits = 2048

default_keyfile = oats.key

encrypt_key = no

default_md = sha1

prompt = no

distinguished_name = my_req_distinguished_name

req_extensions = my_extensions

[ my_req_distinguished_name ]

C = CH

ST = Zurich

L = Zurich

O = mycompany

CN = example.com

[ my_extensions ]

basicConstraints=CA:FALSE

subjectAltName=@my_subject_alt_names

subjectKeyIdentifier = hash

[ my_subject_alt_names ]

DNS.1 = example.com

DNS.2 = *.example.com

DNS.3 = uaa.example.com

DNS.4 = *.uaa.example.com

Step 4 – create a tls certificate signing request (csr) file using a oats config file.

openssl req -new -key example.com.key -out example.com.csr -config oats.conf

To verify the just created example.com.csr :

openssl req -in example.com.csr -noout –text

Step 5 – sign the certificate.

I created a config file that called oats.extensions.cnf. The oats.conf was created to create the csr with this config but for signing the csr with an extension V3 for SAN I would create a new conf file just to make it more clear and separated..

The oats.extensions.cnf is needed because I need a SAN certificate covering all needed DNS hostnames in one certificate and this extension need to be passed to the certificate when it gets signed.

Important: follow this link and create the ca.cnf and oats.extensions.cnf prior signing the csr file.

https://gist.github.com/Soarez/9688998

In your working directory create files and subdir as explained in the link above. The root CA file need to be ca.crt and the private key file name is ca.key. If you use different file names then you have to either modify it in the ca.cnf file to fit your needs or change the file names to ca.crt and ca.key accordingly.

Additionally don't forget to issue below commands from your working directory as these steps are needed by our ca.conf specifications.

$ mkdir newcerts

$ touch index.txt

$ echo '01' > serial

Important: stay in our current working directory and do not change to subdirector “newcerts”.

Sample oats.extensions.cnf:

basicConstraints=CA:FALSE

subjectAltName=@my_subject_alt_names

subjectKeyIdentifier = hash

[ my_subject_alt_names ]

DNS.1 = example.com

DNS.2 = *.example.com

DNS.3 = uaa.example.com

DNS.4 = *.uaa.example.com

Now we sign the csr:

openssl ca -config ca.cnf -out example.com.crt -extfile oats.extensions.cnf -in example.com.csr

To verify the certificate:

openssl x509 -in example.com.crt -noout –text

Now we finished the tsl SAN certificate creation part.

Let’s move on to use the certs and deploy CAP using nginx-ingress.

Fortunately, SUSE documentation greatly explains the steps to deploy CAP with nginx-ingress and the only thing you need to do is to read and follow the instruction in the SUSE Cap 1.4 official documentation - chapter Using an Ingress Controller with Cloud Application Platform

Step 9 in the documentation is to test either you could reach uaa.example.com with your rootCA file. This step is very important and shows if the tls handshake is working and uaa is running well.

curl --cacert INGRESS_CONTROLLER_CA_CERT https://uaa.example.com/.well-known/openid-configuration

The correct result should look like followings: (curl command without -k)

curl --cacert ./k8s/cap/ca.crt https://uaa.bocap.cloud/.well-known/openid-configuration

{"issuer":"https://uaa.bocap.cloud:443/oauth/token","authorization_endpoint":"https://uaa.bocap.cloud/oauth/authorize","token_endpoint":"https://uaa.bocap.cloud/oauth/token","token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"token_endpoint_auth_signing_alg_values_supported":["RS256","HS256"],"userinfo_endpoint":"https://uaa.bocap.cloud/userinfo","jwks_uri":"https://uaa.bocap.cloud/token_keys","scopes_supported":["openid","profile","email","phone","roles","user_attributes"],"response_types_supported":["code","code id_token","id_token","token id_token"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256","HS256"],"id_token_encryption_alg_values_supported":["none"],"claim_types_supported":["normal"],"claims_supported":["sub","user_name","origin","iss","auth_time","amr","acr","client_id","aud","zid","grant_type","user_id","azp","scope","exp","iat","jti","rev_sig","cid","given_name","family_name","phone_number","email"],"claims_parameter_supported":false,"service_documentation":"http://docs.cloudfoundry.org/api/uaa/","ui_locales_supported":["en-US"]}

Once this step is successful you can move one to deploy SUSE Cloud foundry (scf).

Step 11 in the documentation is another critical point where you have to generate an environment variable with content from your rootCA file. Our self generated root CA needs to be passed to cloud foundry deployment as the router pod need to communicate to https://uaa.example.com and will need our CA to trust the domain.

export INGRESS_CA_CERT=$(cat ca.crt)

Make sure you took the correct rootCA file. In my case it is the file "ca.crt"

You can verify it by:

echo $INGRESS_CA_CERT

-----BEGIN CERTIFICATE----- MIIGBzCCA++gAwIBAgIUW1+GonYyRvt9V6dijb9yYKQE5RAwDQYJKoZIhvcNAQEL BQAwgZIxCzAJBgNVBAYTAkNIMQwwCgYDVQQIDANadWcxDTALBgNVBAcMBENoYW0x FzAVBgNVBAoMDlNVU0VDT05TVUxUSU5HMQ4wDAYDVQQLDAVCb0ppbjEUMBIGA1UE

......continues.....

... VQQGEwJDSDEMMAoGA1UECAwDWnVnMQ0wCwYDVQQHDARDaGFtMRcwFQYDVQQKDA5T S8jNER9ZaOEVKSBguXFJRHFxF3icxIgQCxTHFNYKaTapXg5IAwjaQ3VeOuUbHau/ qXD/qH2DptR4Pg019G7EDP+HLvjbwuASfDWwf1eMZ46irlRGZbZf9OUgqP+uhBM5 Z8qOVK028iMfhT3l+Bas8Q/xJT+Jr97VswdQR8PuvHQSiW78EMTIcNMf3pSv9XHb m5/eAMi+R6N4jtg= -----END CERTIFICATE-----

Troubleshooting:

One mechanism I learned from developers to get a log collection is using klog provided by SUSE Development.

Run below command on your linux client from where you use kubectl and cf commands. The output will be a tar.gz file with logs and information collected.

wget "https://raw.githubusercontent.com/SUSE/scf/develop/container-host-files/opt/scf/bin/klog.sh" && bash ./klog.sh

You can use this script and read the log files and descriptions about the entire SUSE CAP deployment or send it to somebody else or SUSE Support requesting help.

Good Luck!