#Problem Applying SSL Cert

1 messages · Page 1 of 1 (latest)

boreal mulch
#

I'm having some problems applying SSL certs to my Nabox. I'm reading different things about what the process is and it's confusing.

  1. Do you need to paste something into the private key field?

  2. Does the root chain section need to be just the server and intermediate cert only?

  3. Everything needs to be in .pem format?

desert summit
boreal mulch
#

@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.

desert summit
#

sorry to hear that @boreal mulch, let's see what @worldly onyx says

worldly onyx
#

Did you send an email to nabox help already ? I’m assuming you’re the same person

boreal mulch
#

Yes, this is easier because I don't have access to email when not in the office.

worldly onyx
#

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.

boreal mulch
#

@worldly onyx This has been done several times already and still not working.

worldly onyx
#

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 ?

boreal mulch
#

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.

worldly onyx
#

Maybe they add it in the returned cert. what about dc logs nabox-api ?

boreal mulch
#

Just some GET and POST messages

worldly onyx
#

ls -l /opt/ssl ?

#

We can work over teams/zoom if you want/can

boreal mulch
#

the .crt and kety files

worldly onyx
#

do you have both nabox-api and nabox-admin running in dc ps ?

boreal mulch
#

Sure do

worldly onyx
#

do the crt and key file have both sizes (not empty)

boreal mulch
#

Yep

worldly onyx
#

Can we do a remote session ?

boreal mulch
#

Yes

worldly onyx
#

I can zoom

worldly onyx
#

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

worldly onyx
#

I can reproduce, will keep you updated

boreal mulch
#

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.

worldly onyx
#

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 ?

boreal mulch
#

No I cannot unfortunately.

#

So, should I just scrap this for now?

worldly onyx
#

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 ?

boreal mulch
#

Let me check

#

THey do not

worldly onyx
#

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

boreal mulch
#

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?

worldly onyx
#

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)

worldly onyx
#

it's possible that you're using the wrong file in the package of certificates in different shapes and form you get

boreal mulch
#

You mean not using the correct .csr that was generated?

worldly onyx
#

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)

boreal mulch
#

I'm using the .pem file chain without root.

#

So only server and intermediate.

worldly onyx
#

ok, If I got that right, that pem has 2 certs correct ?

boreal mulch
#

Yep

worldly onyx
#

ok, maybe you can swap'em and see if the modulus matches

boreal mulch
#

And them the private ky is already a .pem

worldly onyx
#

That would be silly from the CA to return them in inverted order but at this point...

#

so they do return a private key ?

boreal mulch
#

No

worldly onyx
#

ok

#

In that case the only thing I see is to swap the two certs in the file and then check the modulus

boreal mulch
#

Already did

worldly onyx
#

dang it

boreal mulch
#

Didn't work

worldly onyx
#

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

boreal mulch
#

.pem, .crt, .cer

worldly onyx
#

And they all contain the same thing ?

boreal mulch
#

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?

worldly onyx
#

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 ?

boreal mulch
#

openssl and no passphrase

worldly onyx
#

and you also tried using swagger ?

boreal mulch
#

/usr/bin/openssl req -sha256 -new -key ${DNSNAME}.key -out

#

No to swagger

worldly onyx
#

ok let me try with your method

boreal mulch
#

The basic Linux method for SSL

#

Nothing fancy

worldly onyx
#

Would you mind putting the exact command ?

boreal mulch
#

I cannot

worldly onyx
#
nabox-api:~# /usr/bin/openssl req -sha256 -new -key ${DNSNAME}.key -out
req: Option -out needs a value
boreal mulch
#

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

worldly onyx
#
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

boreal mulch
#

I recreated the private key and .csr and they now match

worldly onyx
#

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

boreal mulch
#

I have to send off to CA again

worldly onyx
#

lol

#

oh your csr didn't even match ?

#

interesting

boreal mulch
#

I don't know at this point after all I have done.

worldly onyx
#

Yep we'll take the win

boreal mulch
#

So let's see what happens after I get what I need from the CA.

worldly onyx
#

Yes let me know

boreal mulch
#

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.

worldly onyx
#

makes sense

boreal mulch
#

It worked this time. THanks for all of your help!

#

After generating a new private key and csr and getting new signed certs returned. I applied just what I mentioned, the private key and the .pem file that had server and intermediate certs, without the root.