NSX-T Certificate Replacement

[NetRock]

Hello,

I am trying to replace default self-signed certificate of NSX-T Manager. I followed the procedure that explained on NSX-T Documentation but stuck in certification verification step.

The CSR is generated from NSX-T Manager UI under System, Certificates, CSRs tab. I used Microsoft CA and through submit the certificate request through Web enrolment interface.

I used Web Server certificate template, also another certificate template that I previously created for NSX-V, and exported the certificate chain with Base 64 encoded.

The exported certificate chain is imported to NSX-T but before replacing the certificate, I ran following REST API call to validate the certificate;

GET https://<nsx-mgr>/api/v1/trust-management/certificates/<certificate-id>?action=validate

But I got this error on Postman.

{

  "status" : "ERROR",

  "error_message" : "Certificate is not compliant as certificate of type SERVER: Basic constraints Extension is not present in the certificate"

}

I asked around but seems that many people had the same experince and couldn't replace the self-signed certificates.

Anyone could run this process with Microsoft CA successfully?

Best,

NetRock

[daphnissov]

Yes, done it dozens of times with no issues. You're either generating the certificates incorrectly or not supplying them correctly. Without seeing them and having more details, it's just guess work.

[NetRock]

Hello daphnissov,

Thanks for your answer. Do you have a detailed guide on how to generate the certificate and supply the certificate so I can follow? For NSX-V, the instructions are very clear but couldn't find a good one o NSX-T!

Best,

NetRock

[daphnissov]

Use the CertGen tool as detailed here. For some basic usage that I show (although it's pretty much covered in that KB), you can refer to one of my blog posts here.

[Brian OConnell]

There were some changes to the certificate requirements in NSX-T 3.0 that required basic constraints enabled on the template. See the VVD 6.0 guidance here for creating the template Create and Add a Microsoft Certificate Authority Template in Region A

[TronAr]

Hmm, I've just tried to replace a test NSX-T 3 manager certificate and failed.

What I did:

-went to nsx manager ui system/certificates page and generated a CSR.

No options there, just a not so evident field description of "name" and "common name". I guess name is just an alias.

-took that CSR and generated a cert. (no, I'm not using windows CA)

-imported the cert (fullfilled the CSR) and imported the CA cert (root cert)

-resynched certs (because of an alert, i.e. start search resync manager)

-got new cert ID

-tried to assign that ID to https service via REST (v1/node/services/http?action=apply_certificate)

That last step responded with

{

  "error_code": 36432,

  "error_message": "Certificate validation failed. Reason : Certificate is not compliant as certificate of type SERVER: Extended key usage field not present in the certificate.",

  "module_name": "node-services"

}

which is odd because I don't see amy way to change the CSR content.

[daphnissov]

What probably happened is whatever system you used to generate this cert from the CSR did not sign it as a server/machine certificate. You need to look at what template/settings were used on your CA to sign this cert.

[TronAr]

Indeed, the signing left out some requested extensions!

Certificate Request:

    Data:

        Version: 1 (0x0)

        Subject: C = AR, ST = Buenos Aires, L = Martinez, OU = Training, O = Trace On Consulting, CN = nsx.ba.ar

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                RSA Public-Key: (2048 bit)

                Modulus:

                    00:ba:91:9c:19:6e:a6:29:6b:2e:57:3e:a0:70:06:

..

                    1b:45

                Exponent: 65537 (0x10001)

        Attributes:

        Requested Extensions:

            X509v3 Extended Key Usage: critical

                TLS Web Server Authentication, TLS Web Client Authentication

            X509v3 Basic Constraints: critical

                CA:FALSE

    Signature Algorithm: sha256WithRSAEncryption

         9a:7e:92:01:13:19:00:94:a3:63:23:49:30:f9:fd:2c:5f:11:

  ..

         e9:94:54:56

Certificate:

    Data:

        Version: 1 (0x0)

        Serial Number:

            f4:e0:62:72:67:54:ed:e0

        Signature Algorithm: sha256WithRSAEncryption

        Issuer: C = AR, ST = Buenos Aires, L = Martinez, O = Trace On Consulting, CN = TestCA, emailAddress = [e-mail]

        Validity

            Not Before: Jun 23 12:15:35 2020 GMT

            Not After : Jun 21 12:15:35 2030 GMT

        Subject: C = AR, ST = Buenos Aires, L = Martinez, OU = Training, O = Trace On Consulting, CN = nsx.ba.ar

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                RSA Public-Key: (2048 bit)

                Modulus:

                    00:ba:91:9c:19:6e:a6:29:6b:2e:57:3e:a0:70:06:

...

                    1b:45

                Exponent: 65537 (0x10001)

    Signature Algorithm: sha256WithRSAEncryption

         12:17:e9:3b:4a:db:4c:77:60:9d:7e:75:c9:65:d7:2a:2b:40:

   ,,,

         8a:d5:19:9e

Thanks.

[TronAr]

Now it does not like the cert.

{

  "status": "ERROR",

  "error_message": "Certificate CN=nsx.ba.ar,O=Trace On Consulting,OU=Training,L=Martinez,ST=Buenos Aires,C=AR was not verifiably signed by CN=nsx.ba.ar,O=Trace On Consulting,OU=Training,L=Martinez,ST=Buenos Aires,C=AR: certificate does not verify with supplied key"

}

It seems that you can not do a new cert w/o changing the RSA key ? Because I have not specified a key when signing an NSX generated CSR.

What's the point of having a CSR page if the cart can not be matched to the actual key ?

Is there a document that baby steps the changing of the node certs ?

This all started because aparently vcenter does not trust NSX when trying to deploy workload management (i.e. vsphere for K8S) and I'm trying to make that trust relation.

[daphnissov]

I generally do not use the CSR function provided by NSX-T Manager, but it should work. Whenever you generate a new CSR, a new private key is typically generated. So I'd just start the process over and get the CSR signed again, add the CA cert to NSX Manager first, then add the machine cert. This is 3.0 so you need to enable trust before adding the compute manager.

[TronAr]

Well, that was the order. I had already loaded the CA and rerun the CSR/sign/import cycle.

The imported cert does not validate. The apply_certificate says it can not be validated by itself (?) and the validate method says the key does not match.

I'll import a cert/key pair... I'll have to dig into the trust management framework. Any pointers ?

Thanks again!

[daphnissov]

I mean, it's a fairly straightforward process but I don't quite know everything that you did, how, and in what order. It seems whatever CA and signing system you used it doesn't like, which is usually where this process breaks down. The process is well documented for Microsoft CAs, but you're not using that. The other thing to check is that the cert you pass it needs to contain the full chain with the machine cert at the top followed by any intermediate certs, and finally the root CA. This was a change compared to 2.5 if I remember correctly. Also check and ensure the cert you're signing using a modulus and signing algorithm which is supported. Check the docs for that info.

[TronAr]

Ah, I'm not returning a chain, just the cert. That sounds like it.

It would be nice for the UI to ask for a chain though :smileyhappy:

Now it rejects for lack of CDP for CRL checking. Argh. I've found a KB that talks about disabling it (VMware Knowledge Base ),

but REST fails:

{

    "module_name": "common-services",

    "error_message": "Method is not allowed",

    "error_code": 282

}

[TronAr]

That was my bad, I was using POST instead of PUT.

After that, cert was finally accepted.

Thanks++.

[chesed82]

Did you make a certificate file for NSX-T Manager with RootCA Cert?

NSX-T Manager's certificate have to involve RootCA Cert.

Cert format is below.

<NSX-T Manager Cert>

<ROOTCA Cert>

for example, in nsx-t.crt file

-----BEGIN CERTIFICATE-----

This is a certificate for NSX-T Manager

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

This is a certificate for RootCA

-----END CERTIFICATE-----

[TronAr]

Yes, after being pointed in that direction.

That's what AFAIK is called a certificate chain. Thanks.