D3 and mvBase

 SSL Certificates

posted 02-02-2021 21:41

G'day all

 

Been having some issues with getting the SSL certificate to work with MVS toolkit. We’ve had it working once before, with a massive amount of tweaking within the certificate to get it working. This time we’re moving to a wildcard certificate and despite going through the same steps (and the same tweaking) we’re having no luck.

 

Has anyone got a wildcard SSL certificate working with MVS Toolkit? And do you have a consistent procedure to get this to work?

=================

 

The main thing is the consistency – so we can do the same thing each time and get it working without stuffing around with it.

ROCKETEER
Hey, Alex, Brian Cram here.

I'm not sure how a wildcard certificate differs from a standard .PEM CA-supplied certificate. I'll need to research this with Engineering.

Meanwhile, for anyone else who's listening, here's a video showing how to use a standard CA-supplied certificate to enable HTTPS with the MVS Toolkit. Alex, you've already seen this, so it's old news to you:

https://youtu.be/cisPRGAAWNs
the only difference between these types of certificates is that the normal certificate is fixed to a subdmonio and domain just for example:
d3.site.com
the wilcard certificate it accepts all subdomains of the domain getting:
* .site.com
that is, all subdomains are certified by it for example:
d3.site.com
u2.site.com
mv.site.com
ROCKETEER
Thanks, Alberto. I'm still looking into this.
ROCKETEER
Hi, Alex. I had a meeting with your guy and MBS ( you were invited but I don't think you joined ). We went through the process and here's what we determined:

The problem with importing the wildcard certificate into the MVS Toolkit keystore had nothing to do with the fact that it was a wildcard certificate but rather that it was not from a sufficiently-trusted Certificate Authority. The way they got around it was to create a .PEM file that had a sufficiently-trusted certificate followed by the wildcard certificate followed by the private key as follows ( edited for brevity and security ):

 

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

MIIFvjCCBKagAwIBAgISAzMCsFkt1ZFCjM1IW9vy3ERVMA0GCSqGSIb3DQEBCwUA

( edited )

ExYXodzx1ZjG4Lr1S0d2S+psKWy41Yqwg8a1/nGKMi5exQ==

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

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

MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/

( edited )

UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg==

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

-----BEGIN RSA PRIVATE KEY-----

tQ2TKKvqoK/5jWhD50tdZEQVEFJUXVMvmw08TwIDWpVEDZd8+L40y8aAB9FqGX7z

( edited )

bxU8rX3s9YnMMGyp4BiKGPoiDTGsiE9v+vVorcYW3XGOZaPrjlpMcorI6Ugk0Dwj

-----END RSA PRIVATE KEY-----

 

The steps for creating the Java Keystore used by the MVS Toolkit were:

 
1) Aggregate the two certificates and private key into on .PEM file

 

2) Use OpenSSL to convert the .PEM file to a .PKCS12 file

 

3) Use the JDK's keytool utility to create an empty keystore file ( .KS )

 

4) Use the JDK's keytool utility to import that .PKCS12 file into that keystore file ( .KS )

 

One annoyance is that if there are any failures using OpenSSL and/or keytool, the errors thrown are rather cryptic. This is not a weakness in the Toolkit itself, but rather the third-party open-source utilities: OpenSSL and the JDK ( Java Development Kit ).

 

The good news is that your resource now knows how to do this easily and will be able to deal with certificate expiration very easily next time.