X509: certificate relies on legacy Common Name field, use SANs instead

Building/Development
8

It's been a journey for sure.

The main objective is to provide a simple service that turns websites dark.

  • light access is provided over the public DNS
  • dark access is provided over a ziti network fabric

To make user accounts accessible over a ziti network without needing to duplicate the website.. I am using a golang server to act as a reverse proxy that operates over a ziti network.

While this is not "the solution" it is a simple first step to get started.. and implement a deeper AppWAN in a later implementation.

The business opportunity is to sell reverse proxy service on demand .. automating the process of creating a network fabric for user account management
this means that users will no longer access user account function over a public DNS

As you can see in the image below.. I can redirect a private DNS over a ziti network to my website...https://www.markamind.com

1650963775109

Here is a summary of what is happening

  1. user starts the Ziti Desktop edge tunneller
  2. user types in a http address that I have setup an intercept for
    http://golanghttp.zitified:2000

note: even though the traffic is going over http.. its still encrypted.. because I believe this is what the network fabric is doing.. @TheLumberjack discussed this in another post here.. but I still dont understand it 100% yet
Integrating OpenZiti with a Golang TLS server - #15 by TheLumberjack

  1. the intercept picks up http request.. and sends it to a ziti service
  2. The ziti service sends the http request to a "zitified" golang https server that then connects to the origin server over https .. and returns the request back to the user... without the user accessing the origin server

phew.. it took me some time to even explain that

As you can see.. this works... but what I did not know was why it worked because at the time I had no idea of what I was doing :slight_smile:

What I understand now is that the reason why this worked can be seen in how the certificate is created for my website

Screen Shot 2022-04-27 at 9.09.41 am
Screen Shot 2022-04-27 at 9.09.41 am1520×884 115 KB

You will notice that it is created using a wildcard DNS name.
this is why I didn't get this error coming back from the Golang reverse proxy

x509: certificate relies on legacy Common Name field, use SANs instead

So.. with my new found confidence.. I though I would try something a bit harder.. and replicate this same situation using an Oracle Apex application hosted on Oracle Cloud.. which is when all of the problems happened.

  1. I don't remember exactly what happened at the time.. but rather than using the public dns of the hosted Apex application.. I needed to use a proxy server.. so I decided to deploy ORDS on a private compute..
  • this got me a bit further... but I got stuck because I built ORDS using a self signed certificate.. this did not work because my ziti network does not trust the new "certificate authority" that I created
  1. I decided to return back to my website to see if I could reproduce the problem..
  • I broke it.. long story short.. the reverse proxy forwards the user to the origin server if I use http://markamind.com.. but is not for http://www.markamind.com
  • I thought this was a problem with my Goloang code.. but it was not.. I have a redirect on the DNS server
  1. I tried to reuse the the certificate and key created when I did the quick install. I thought this should be trusted because it was created by the "ziti" Certificate Authority
  • the problem is.. the certificates created do not have a SAN (Subject Alternative Name). Apparently.. this is now a requirement for a Goloang reverse proxy server.

This is why I received this error back from the Golang reverse proxy when i used the certificate and private key created by the Ziti Quick Install

x509: certificate relies on legacy Common Name field, use SANs instead

  • I think this would not work anyway because when I built the controller.. I used an IP address.. so if the quick start program created a SAN.. it would not have matched the URL I was using

After all of this.. I realised you can "verify" a Certificate Authority in Ziti..

I have another post about this.. I believe this will be the "preferred" alternative.. but I still need to work through the details

if you are game enough to venture into this space.. here is a great introduction on how to build a Certificate Authority.. if you follow the steps you will get 95% there.. you will reach a problem when you want to create a client certificate to validate the Certificate Authority in ziti..

https://jamielinux.com/docs/openssl-certificate-authority/introduction.html

Here are the commands that I used to create it

  1. create the user private key

openssl genrsa -aes256
-out intermediate/private/X4EA4CxdE.key.pem 2048
chmod 400 intermediate/private/X4EA4CxdE.key.pem

  1. create the certificate signing request

openssl req -config intermediate/openssl.cnf
-key intermediate/private/X4EA4CxdE.key.pem
-new -sha256 -out intermediate/csr/X4EA4CxdE.csr.pem

  1. create the user certificate

openssl x509 -req -in intermediate/csr/X4EA4CxdE.csr.pem -CA intermediate/certs/ca-chain.cert.pem -CAkey intermediate/private/intermediate.key.pem -CAcreateserial -days 365 -sha256 -extfile intermediate/client_cert_ext.cnf -out intermediate/certs/X4EA4CxdE.cert.pem

note I used the "intermediate CA". if you use the "root CA" it will not verify

1 Like