#Problem Applying SSL Cert
1 messages · Page 1 of 1 (latest)
hi @boreal mulch, @worldly onyx is the one to ask but he's offline at the moment. Did you try the steps listed here? https://nabox.org/documentation/configuration/#ssl
@desert summit Yes and they are vague as heck and didn't work.
@boreal mulch I have tried applying certs every which way and it just doesn't want to work and allow access to the GUI afterwards.
sorry to hear that @boreal mulch, let's see what @worldly onyx says
Did you send an email to nabox help already ? I’m assuming you’re the same person
Yes, this is easier because I don't have access to email when not in the office.
Understood. Let me paste my reply
At the bare minimum, you should be able to paste any private key with the matching certificate followed by the intermediate(s) certificate, root not necessary.
As long as the key matches the cert and the certs are put in order starting with the server cert followed by the signing CA in order it should work
Everything should be using pem encoding with the section markers.
Also, you can test bypassing web ui and simply put nabox.key and nabox.cer (from memory, might be crt) in /opt/ssl and restart traefik container with dc restart traefik.
To reset ssl setting you can remove key and cert file and do dc down followed by dc up -d to reset with a new self signed.
@worldly onyx This has been done several times already and still not working.
Btw not having the server name in the SAN section will be rejected by many ssl implementation. But it should not prevent traefik to start
Ok, what is traefik saying in dc logs traefik ?
Would you be able to try and match key and certificate in a tool like https://www.sslshopper.com/certificate-key-matcher.html ?
Use this tool to check whether your private key matches your SSL certificate. View the public key hash of your certificate, private key, and CSR to verify that they match.
Logs say something about not being able to connect to 172.19.0.9 remote host
Also, our CA won't allow CN or SAN in the request for certs.
Maybe they add it in the returned cert. what about dc logs nabox-api ?
Just some GET and POST messages
the .crt and kety files
do you have both nabox-api and nabox-admin running in dc ps ?
Sure do
do the crt and key file have both sizes (not empty)
Yep
Can we do a remote session ?
Yes
I can zoom
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference room solution used around the world in board, conference, huddle, and training rooms, as well as ex...
Thanks for your time ! So it seems NAbox isn't writing the key file, I'll do some tests with 3.4 and see if I can reproduce
I can reproduce, will keep you updated
I can't get to the appliance from Chrome but that's probably an internal problem. Neither in incognito mode.
I will just use Firefox for now.
Wrong
After all of that, we are right back to not being accessible again.
I will check certificates match.
But maybe this means 3.4 is not ready for primetime???
The keys still match.
Good luck in your testing. Just let me know if I should just downgrade if possible or do I need to reinstall the entire .ova.
Ok It was probably a bit late last night, I though I reproduced it but I was actually using a wrong certificate. I did fix the fact it's messing up with the certs and break NAbox access, with the new version you'll get an error saying the certs don't match the key, but then I'm still confused by the error you're getting.
Is it possible that your CA is returning certs out of order ?
Would you be able to send me a sample key and cert chain ?
Understood. I do think the first certificate in the chain doesn't match the private key, I'm guessing you can't use an online service either to check it.
Let's see what happens assuming you have a nabox.key containing your private key and a nabox.crt containing the certificate chain : what if you run the following commands :
openssl rsa -modulus -noout -in nabox.key | openssl md5
openssl x509 -modulus -noout -in nabox.crt | openssl md5
Do they match ?
Ok, so now it would be interesting to see if any of those in the chain do
from what I see, those openssl commands look into the first certificate in pem file
Yeah I'm at a loss of where to go from here.
I mean, is the CN and SAN a requirement, could that be a problem?
What fooled me when I was testing after our chat is that my pki gives me a chain with no cer, and the cer separate, I mistakenly used the chain file (which didn't contain the cer)
I don't think so, it wouldn't prevent the web site to run
it's possible that you're using the wrong file in the package of certificates in different shapes and form you get
You mean not using the correct .csr that was generated?
I think the csr is fine, as it's accepted by your CA and they return with a bunch of certs.
So I would assume they return a package that doesn't contain a private key (but if they do, you certainly want to use it instead of the one you have locally)
ok, If I got that right, that pem has 2 certs correct ?
Yep
ok, maybe you can swap'em and see if the modulus matches
And them the private ky is already a .pem
That would be silly from the CA to return them in inverted order but at this point...
so they do return a private key ?
No
ok
In that case the only thing I see is to swap the two certs in the file and then check the modulus
Already did
dang it
Didn't work
can you list the different files you get from the CA
Also can you check the two commands without | openssl md5 see if the output is actually valid
.pem, .crt, .cer
And they all contain the same thing ?
Yes
The server cert in all formats are the same.
Same with root and intermediate
So did you get your environment to work consistently using 3.4?
No I couldn't reproduce, and the reason is that my certificates match, for some reason yours don't, as the openssl command shows
But there has to be something we're missing, I don't see why you wouldn't get a correct certificate from the CA
I did fix the bug that messed up the web server though, now you would get the correct error message
Well, the answer is 3.4 works fine in my lab
maybe there is something. How did you generate the private key again ? does it has a passphrase ?
openssl and no passphrase
and you also tried using swagger ?
ok let me try with your method
Would you mind putting the exact command ?
I cannot
nabox-api:~# /usr/bin/openssl req -sha256 -new -key ${DNSNAME}.key -out
req: Option -out needs a value
Let me append the command for you
DNSNAME=
EMAILDISTRO=
/usr/bin/openssl genrsa -rand /dev/urandom 2048 > ${DNSNAME}.key
/usr/bin/openssl req -sha256 -new -key ${DNSNAME}.key -out ${DNSNAME}.csr -subj "/C /L /O /OU /CN /emailAddress=${EMAILDISTRO}" 2>/dev/null
/usr/bin/openssl req -text -noout -verify -in ${DNSNAME}.csr | grep 'Subject:|Algorithm|DNS|Public-Key' | tr -d ' '
/bin/cat ${DNSNAME}.csr
You have to edit the "req" information
nabox-api:~# openssl rsa -modulus -noout -in nabox.home.lab.key |openssl md5
MD5(stdin)= 6d675422b8fdd3368037185b4632d2ae
nabox-api:~# openssl x509 -modulus -noout -in nabox.home.lab.cer |openssl md5
MD5(stdin)= 6d675422b8fdd3368037185b4632d2ae
nabox-api:~# /usr/bin/openssl req -sha256 -new -key ${DNSNAME}.key -out ${DNSNAME}.csr -subj "/C=FR/L=Paris/O=NetApp/OU=NAbox/CN=nabox.home.lab/emailAddress=${EMAILDISTRO}"
seems to be working, certificates match
I recreated the private key and .csr and they now match
I'm afraid you'll have to reach out to your CA people and try to undertsand what you're not getting a matching cert
I have to send off to CA again
I don't know at this point after all I have done.
Yep we'll take the win
So let's see what happens after I get what I need from the CA.
Yes let me know
Yep
I'm gong to convert private .key to .pem, apply. Then apply the .pem file that has the server and intermediate certs. That should work.
makes sense