We recently completed an integration project involving mTLS client certificates across both our TCG and TCW device series.
The TCG series uses SIMCOM cellular modules with a built-in TLS stack. The TCW series uses our own controller hardware and embedded TLS implementation.
Both series had to connect to the same server over mTLS. The customer also wanted to use the same mTLS client certificates across the entire fleet.
On paper, this looked straightforward. Both series support standard mTLS.
In practice, things were more complicated.
Here is what we learned and the certificate and server requirements we now recommend.
The starting point: one certificate, two device series
The original plan was simple.
Generate one client certificate, sign it with one CA, and install it on devices from both series. Then configure the server once.
During testing, however, TCG and TCW devices behaved differently with the same server configuration. A connection that worked with one series could fail with the other.
At first, there was no obvious reason for the difference.
Why we standardized on RSA for mTLS client certificates
Both series list ECDSA P-256 and P-384 as supported certificate types.
In practice, ECDSA client certificates did not work reliably with TCW devices in client mode during our testing. This happened despite the capabilities described in the underlying TLS library documentation.
This highlights an important distinction.
Library documentation describes what the TLS library can support. It does not necessarily describe what a specific device enables and verifies in its client-mode implementation.
RSA behaved differently.
RSA certificates worked consistently across both device series during our tests.
It gives us one certificate type that works across the complete fleet without requiring separate configurations.
mTLS Client Certificate Formats: PEM vs. DER and PKCS#1 vs. PKCS#8
Two certificates can contain the same key and still behave differently because of their format.
PEM vs. DER
PEM is a text-based format. It uses markers such as:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----DER contains the same type of certificate data in binary form.
Not every embedded device handles both formats in the same way.
PKCS#1 vs. PKCS#8
RSA private keys also commonly use two different containers.
PKCS#1 is the older RSA-specific format. It normally uses:
-----BEGIN RSA PRIVATE KEY-----PKCS#8 is an algorithm-independent container. It normally uses:
-----BEGIN PRIVATE KEY-----A PKCS#8 container can hold either an RSA or an EC key. Therefore, the header alone does not tell you which key type it contains.
During our testing, PEM-encoded RSA keys in PKCS#1 format worked with both TCG and TCW devices without an additional conversion step.
mTLS Client Certificates: Only Half the Story
After solving the certificate compatibility issues, we still encountered connection failures.
This time, the server configuration caused the problems.
We identified four important areas.
1. Elliptic curve negotiation happens even with an RSA certificate
Using an RSA certificate does not necessarily remove elliptic curves from the TLS handshake.
For example, an ECDHE_RSA cipher suite uses RSA for authentication but ECDHE for key exchange.
The key exchange therefore still requires elliptic curve negotiation.
During our testing, the server’s default curve worked with one device series but caused the other series to fail during the handshake. The failure occurred before certificate verification.
We solved this by configuring the server to negotiate a widely supported curve such as P-256 or P-384.
A static RSA key exchange cipher suite can avoid elliptic curve negotiation completely. However, static RSA does not provide forward secrecy.
For this reason, we consider it a fallback rather than the preferred solution.
2. Signature algorithm negotiation can exclude a device
TLS 1.2 supports several RSA signature schemes.
These include classic PKCS#1 v1.5 RSA signatures and the newer RSA-PSS scheme.
One of our device series supports only the former.
If the server offers only PSS-based signature algorithms, client authentication fails on that device series. This can happen even when the device contains a valid RSA certificate.
3. Check the server trust store
During testing, we changed to a new CA.
In one environment, we temporarily forgot to add the new CA to the server’s list of trusted client CAs.
The resulting failure looked very similar to a client certificate problem. The TLS process reached certificate verification, but the server rejected the certificate.
The certificate itself was valid.
The server simply did not trust its CA.
4. Make sure mTLS is actually mandatory
A server can accept client certificates without requiring them.
We encountered this situation during testing.
The server accepted a client certificate when the device provided one. However, it also allowed connections without a valid client certificate.
For a true mTLS configuration, the server must require and verify the client certificate.
This is worth checking explicitly rather than assuming it from the server configuration.
The Takeaway: mTLS Client Certificates
None of these issues is unusual on its own. They are standard TLS behaviors.
The complexity came from using two device series with different embedded TLS stacks against one shared certificate and server configuration.
The symptoms also made troubleshooting harder.
Different problems could produce similar handshake failures, alerts, or certificate rejections.
Our conclusion
When deploying mTLS client certificates across different embedded device families, do not rely only on the individual device documentation.
Test the common configuration directly across all device families.
Then document that configuration clearly.
Use this tested specification when provisioning certificates and configuring the server.