Thanks so much.. I was so excited that I got past the downloading of a JWT file.. I must have missed that bit.. I still cannot believe it.
As a quick additional comment.. I was cleaning up all of my workings and took a look through the router yaml file.
What is interesting is a number of things
- You define the CSR
- You can include SANs
This may change how redo this test in the future... not sure at this point in time..
edge:
csr:
country: US
province: NC
locality: Charlotte
organization: NetFoundry
organizationalUnit: Ziti
# (required) SANs that this Gateways certs should contain. At least one IP or DNS SAN should be defined that matches
# the edge listeners "advertise" value from the "listeners" section.
sans:
dns:
- "localhost"
- "test-network"
- "test-network.localhost"
- "ziti-dev-ingress01"
email:
- "admin@example.com"
ip:
- "127.0.0.1"
uri:
- "ziti://ziti-dev-gateway01/made/up/example"
I checked through the files and found the bundled ca certs file
Though.. what do you do with this file... is this something you copy to the server with the private key?
Let me know if you have any tips
It’s used when enrolling. you MUST provide the full trust store when using openziti. you cannot bypass the x509 check. these commands pull the file, unzip, un “p7” it etc… and put it into that location. it’s then used when enrolling
# you need the CA bundle in order to enroll - this command grabs the ca bundle
curl -sk https://${ZITI_EDGE_CTRL_ADVERTISED}/.well-known/est/cacerts > ${ZITI_PKI}/fetched-ca-certs.p7
openssl base64 -d -in ${ZITI_PKI}/fetched-ca-certs.p7 \
| openssl pkcs7 \
-inform DER \
-outform PEM \
-print_certs \
-out ${ZITI_PKI}/fetched-ca-certs.pem <-- right here
identity_full_ca_path="${ZITI_PKI}/fetched-ca-certs.pem"
reorganized to make it a bit more clear
Here is a screen shot of the enrolled identity… is there a way where I can check that I have it done correctly with the bundled ca cert?
I don’t know if there’s a clear way to tell. The best way would be to look at the identity file (the .json) and verify the cert that is used in that file was signed by the CA. You could also try to attach a ziti-edge-tunnel and verify it works to pass traffic.
1 Like
I think I may need to install the root certificate on the server .. as there are two hosts running on the same machine
#1. the Golang reverse proxy.
#2. the ORDS service
I think this is what is causing the problems.. and needs the self signed certificate installed on the server.
I will try this.. after working out how to do it.. and will revert back
I don't know what problems you're having, but my guess is that your web server isn't serving https properly. The x509 error you cite, I don't expect it's relevant to that problem (if that's your 'problem')
What matters is the certificate which your http server returns. It needs to be valid for the URL you're connecting to.
So if you intercept "https://markamind.ziti" - the https server needs to return a cert valid for "markamind.ziti" but I don't think you will be able to engineer that certificate from a valid third party CA like lets encrypt. For that to work you'll need a legitimate domain to validate against and something like "markamind.ziti" won't be.
Whatever you're up to now though, I'm sad to say I think you're exiting the OpenZiti domain 
I look forward to seeing you successful
!
1 Like
As a final closure on this.. I worked through resolving the remaining.. conflict.
x509: certificate signed by unknown authority self signed certificate
As this was being triggered between the reverse proxy.. and the host server.. (i.e. outside the ziti network) I needed to add the Certificate Authority to the server
Steps were
- copy the CA cert to /etc/pki/ca-trust/source/anchors/
- update-ca-trust enable
- update-ca-trust
1 Like