Category Archives: Misc - Page 6

OpenShift: add project route in web console using yaml example


As soon as I started using YAML for OpenShift configuration I didn’t turn back. It is so much simpler to handle. Project routes can be configured in the web console but you can also import YAML.

Here is an example of such a YAML:

apiVersion: v1
kind: Route
metadata:
  name: myapp
  labels:
    app: myapp
    name: myapp
spec:
  host: mysuperdomain.se
  path: /myapp
  port:
    targetPort: 8080-tcp
  to:
    kind: Service
    name: myapp

NOTE! You need to setup a project service first so you have something to reference in the route (spec/to)

Tested on OpenShift Web Console: v3.11.153

OpenShift: add project service thru web console example

OpenShifts web console can do a lot but adding new project services is only done thru importing yaml file (or text)

Here is one example of such a yaml text

apiVersion: v1
kind: Service
metadata:
  name: myapp
  labels:
    app: myapp
    name: myapp
spec:
  ports:
    - name: 8080-tcp
      port: 8080
      protocol: TCP
      targetPort: 8080
  selector:
    app: myapp
    deploymentconfig: myapp
  sessionAffinity: None
  type: ClusterIP

Tested on OpenShift Web Console v3.11.153

How to check a certificate chain in a jks

This can be done in a number of ways. One common way is to simply but the jks in its environment and see if it works. This is however a little late for my taste. I like to check it BEFORE i put it into a running environment. I will here show 2 ways to check a certificate chain:

  1. Manually check the cert using keytool
  2. Check the chain using openSSL

1. Lets start with the manual check:

keytool -list -v -keystore my.certificate.chain.jks | grep -A 1 "Owner"

This command will list all certifications (and keys) Owner (CN) and Issuer (CN) something like this:

  1. Owner: CN=app.tankmin.se, OU=Secure Link SSL, OU=Tankmin…
    Issuer: CN=Network Solutions OV Server CA 2, O=Network Solutions L.L.C….
  2. Owner: CN=Network Solutions OV Server CA 2, O=Network Solutions L.L.C….
    Issuer: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network…
  3. Owner: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network…
    Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network…
  4. Owner: CN=AddTrust External CA Root, OU=AddTrust External TTP Network…
    Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network…

I have here rearrange them with my application certificate at the top and the root CA certification at the bottom. I have also given every entry a number to easier be able to explain the logic behind the chain.

From here it is pretty simple to see that:

  1. Issuer of my application certificate (no. 1) is Network Solutions OV Server CA 2 and
  2. Issuer of that certificate (no. 2) is USERTrust RSA Certification Authority, and
  3. Issuer of that certificate (no. 3) is AddTrust External CA Root which is the root CA (no. 4)

Since all certificates are linked together down to the root CA the chain is complete. Note: The root CA certificate will always be self-signed

2. And now, if you do not want to do all the above you can use openSSL to verify your application certificate with the following command:

openssl verify -CAfile root.pem -untrusted intermediate.pem application.pem
-CAFile is the root certificate
-untrusted is the intermidiate (if any) certificates
application.pem is your application certificate

The openSSL command above will check the chain to your application certificate and give you a:

application.pem: OK

if all is good

Tested on OpenSSL 1.0.2o 27 Mar 2018 and Java 1.8.0_121