My domain is: cloud.warthan.org I'm running a VMware 7.13 Connection Server in a home lab. When I use a LE cert, the browser throws an error for SSL version or cipher mismatch. A self-signed cert works fine. I've tried the Github WACS in addition to the certbot, and some of the other things I have read here. I can't figure this out, so what am I doing wrong?
Sounds like you are on Windows, so check out Nartac Software - IIS Crypto which is a free tool to manage the associated regsitry settings to enable/disable supported TLS/SSL Ciphers on Windows. I usually apply the 'Best Practices' option, then restart.
The cipher may not be the issue but this would rule that out. What's the actual webserver (IIS?).
1 Like
Cipher mismatch isn't a byproduct of a certificate issue.
It has to do with the ciphers and protocols being used by the system.
There are many best practices (that change over time).
Like:
- Disabling SSLv3, TLSv1.0
- Disabling CRC ciphers
- Using TLSv1.2, TLSv1.3
If not using IIS/Windows, try using the free online SSL Configuration Generator (by Mozilla).
2 Likes
You have issued multiple certificates lately, of which most of them were RSA and just one an ECDSA certificate: https://crt.sh/?q=cloud.warthan.org&deduplicate=y
Please re-use previously issued, valid certificates and not force a renewal: this usually doesn't resolve any issue you have which is not issuance-related, but only increases the load on Let's Encrypt servers.
2 Likes
@webprofusion I tried the Nartac option, but it had no effect. I think VMware is running its own build of Apace on Windows, and it does use the Windows certificate store. The cipher options are stored in an Adam database, which I have also edited by hand.
@rg305 If the error isn't because of the certificate, then why does changing the certificate have an effect? Does the certificate determine the cipher and TLS version used? I ask because I don't know. I did restrict the server to using TLSv1.2/3 and the ciphers selected are TLS ECDHE RSA WITH AES 128 CBC SHA256, and TLS RSA WITH AES 128 CBC SHA.
Osiris, thanks for pointing that out. I'll be careful to re-use without re-issue.
Crap. This shouldn't be this hard... 
1 Like
The answer to this question is not entirely straightforward, but in general, no.
In more detail:
No.
For TLS v1.2 and older, yes*. But only in a minor way.
Cipher Suites for TLS v1.2 and older include the signature algorithm as part of the suite. The signature algorithm must be compatible with the key type of the certificate.
For example, the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 uses the ECDSA algorithm for signatures. This means that this cipher suite can only be used with ECDSA certificates.
On the other hand, this TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is technically the same algorithm, but uses RSA for signatures and can therefore only be used with RSA certificates. Rule of thumb is that each cipher suite that is key type dependent usually has both a version for RSA and a version for ECDSA available (one exception is static RSA, which you shouldn't use anyway).
You can control which key type you generate - you can issue certs from Let's Encrypt with RSA or ECDSA keys, whichever you prefer.
For cipher suites, the general recommendation is to have both ECDSA + RSA cipher suites enabled. TLS libraries will automatically disable suites incompatible with the certificate key, so there's no harm in including them.
For recommended cipher suites you should enable, there's some documentation available in the internet. Mozilla has a great site: Security/Server Side TLS - MozillaWiki
If those are really the only cipher suites enabled, both of these only support RSA keys. Also, both of these are really at the low end, security and support wise. TLS_RSA_WITH_AES_128_CBC_SHA does not even have forward secrecy (static RSA) and uses SHA-1, so even if your TLS stack is patched against the dozen CBC attacks, it's pretty close to insecure.
*For TLS 1.3, cipher suites no longer include the signature algorithm and are thus independent of the key type. Static RSA doesn't exist in TLS 1.3 anymore.
3 Likes
Thanks @Nummer378 I was able to get things working, but I may have a new issue. In my VMware Connection Server, I removed the TLS and Cipher customizations, because I found documentation indicating that the cert needed to have a private key marked as exportable. The customizations are more limitations anyway; Googling for the default ciphers will produce the list VMware uses. So I used WACS to create a PFX and imported that into the Windows certificate store, marking the private key as exportable, reboot, and it works. The previous self-signed cert created by the VMware installer also had a private key marked as exportable, which is why it would work when I switched to it.
I probably could have avoided all of this had I used VMware's Unified Access Gateway (UAG) which is a Linux appliance, and probably doesn't have the same issues. My new problem, and maybe it should be a new thread, is how do I automatically renew this key?
This part is unclear to me:
You used WACS
WACS create a PFX
You imported the PFX to Windows cert store (marked as exportable)
[to then export it back out?]
{some unknown/unexplained step happened here}
BAM! Everything now works!
It is difficult to give any relevant/useful automation guidance when all the steps are unknown/unclear.
But in a very short (and useless) answer: WACS can renew all the certs it obtains (automatically).
[but that won't automate any of the extra necessary (but unknown) steps]
@rg305 I'll clear that up. 
WACS to manually create the PFX file with a private key, with options to save the file to the hard drive. BTW, The WACS option to send the output directly to the certificate store will not mark the private key as exportable. I then load the MMC > Certificates > Computer store, select the folder for personal certs (where VMware wants it), and import the saved file. During the import, I select the option to include the private key and the option to mark the private key as exportable. Further, for VMware connection servers, the friendly name of the cert must be set to "vdm." Reboot.
Let me know if there's anything else I can tell you.
It that the only importing option for VMware?
Eh, sort of. I found this documentation which explains the whole process. It aligns with VMware's documentation. VMware's is a bit too thick to read, and these people made it a lot more digestible. Have look: https://www.ssldragon.com/blog/install-ssl-on-vmware-horizon-view/
That guide makes no mention of the requirement of having the imported cert have the "exportable" attribute.
It does make things a bit clearly (to me).
And seems that VMware will get the cert it needs directly from the Windows Certificate Store (WCS).
If so, there are plenty of Windows ACME clients that can obtain certs and add them to WCS.
I would try them (all if needed) to see which can simplest resolve the problem while maintaining the renewals.
[it really shouldn't be this complicated!]
Yeah, I didn't realize this was the same thing but here is a script for using Certify The Web (get your certificate, then add a Powershell task to automate the deployment): Scripting | Certify The Web Docs. You an probably do the same with wacs.
There's other ways to do it but the key thing is making sure the cert is in the My/Personal local computer certificate store, and setting the friendly name to vdm
1 Like
It does. Under " Import your Server Certificate into a Windows Certificate Store," Step 6, "Select Mark this key as exportable."
These instructions have you create a CSR, selecting " Make Private Key Exportable," and then after you get the resultant certificate, you import it into the certificate store, with the private key, choosing the option to mark the private key exportable.
This IS the thing I previously overlooked. I had the cipher error until I reimported the same certificate but marking the private key as exportable. Now, I don't know why they need this done this way, but alas.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.