NetBurner Community Forum

We have been using SSL with Netburner to connect our devices (as clients) to cloud servers for several years, using a wildcard SSL certificate issued by Digicert. We are expanding our cloud services and are attempting to also use certificates issued by Amazon AWS, in their AWS Certificate Manager (ACM). So far, we are unable to make this work, and we're hoping that we're simply missing something. We have two issues, one more serious than the other.

The most serious issue is failure to validate the server certificate when issued by ACM.

What we have done is:
1. Created the certificate in ACM, and configure our load balancer (standard AWS ELB) with the certificate as an SSL endpoint.
2. Examined the output of "openssl s_client -showcert -connect <DNSname>:443" to determine what the certificate chain looked like, in particular the root certs we needed to compile into our Netburner code.
3. Configured CA certs as described in the Netburner docs into ccerts.cpp and then compiled our system.

We are seeing a failure where even though "Starfield Class 2 CA" is the root of the certificate chain, and is given in ccerts.cpp, we see "Could not get CA for: ,0=Starfield Technologies, Inc.,0U=Starfield Class 2 Certification Authority,C=US" in the SSL debug output.

It is unclear why the code in ParsePeerCerts() should be trying to get the CA for a root certificate compiled into the app. Has anyone seen this issue? More broadly, is anyone using ACM certificates on AWS to do SSL with their Netburner devices as clients, and what did you do to make it work?

The second issue we are seeing is that wildcard certificates (again, issued by ACM) with multiple domain names (alternate names) are failing to find the alternate names when checking if the CN of the requested SSL endpoint belongs within the server certificate's CN and alternate names.

Does the cryptolib support alternate names which are wildcards?

One problem I had with the certs not validating was a bug where a function that claimed it wanted a blob actually used string utility functions inside it, so even though I passed in the private key, the first check it did was to look for the "----- CERTIFICATE" string. Because the two blobs for my certificate and the private key were contiguous in memory and not null-terminated, searching the private key for "----- CERTIFICATE" was successful, the system thought it had the wrong thing, and failed validation.

Can you try a memcpy and copy each cert or private key from the blob array to a slightly larger array and then make sure there is a 0 in the last byte? See if that helps.

I've also seen the strange name formatting in the output. I'm not sure where that comes from, but it happened even when things worked ok. The code that gets the common name from the unhashed cert doesn't necessarily output the whole name or something.

joncard, thanks for chiming in and being helpful.