Hello Everyone,
Have you ever encountered this issue in on-premise environments?
I’m trying to access training environment from the browser and receive this error:
Any help my way is always appreciated.
Kind Regards.
We had the same issue a few days ago with not our training database, but our main Epicor. Tried Chrome and Edge. Seems they are both getting more stringent with certificates.
I have seen others post they have the same error with scanners trying to connect.
Presume they use self-signed certificate as we were?
Only a hunch, but that is the exact error we were getting. ERR_SSL_KEY_USAGE_INCOMPATIBLE.
Here is the other link for another post.
1 Like
As long as the self-signed cert is in trusted authority you can use fine in Edge or Chrome.
PowerShell script to create and install self-signed cert. Just need to create proper binding in IIS after creation.
param (
[Parameter()]
[string]$certname=$($env:COMPUTERNAME), ## Identify the Host this cert is being generated for if not supplied.
[Parameter()]
[string]$dnsname=$($env:COMPUTERNAME+"."+$env:USERDNSDOMAIN ) , ## Build a fqdn we hope if one is not supplied.
[Parameter()]
[string]$pwd = "Please set a password!",
[Parameter()]
[string]$path = "C:\certs" ## Default path to store generated certificate(s)
)
$dnsname = $($dnsname).ToLower()
$mypwd = ConvertTo-SecureString -String $pwd -Force -AsPlainText ## Private Key password
$cert = New-SelfSignedCertificate -Subject "CN=$certname" -CertStoreLocation "Cert:\localmachine\My" -KeyExportPolicy Exportable -KeySpec Signature -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256 -DnsName $dnsname -NotAfter (Get-Date).AddYears(2)
Export-Certificate -Cert $cert -FilePath "$path\lm_$certname.cer" ## Specify your preferred location
Export-PfxCertificate -Cert $cert -FilePath "$path\lm_$certname.pfx" -Password $mypwd ## Specify your preferred location
$certfile = (Get-ChildItem -Path "$path\lm_$certname.cer")
$certfile | Import-Certificate -CertStoreLocation cert:\LocalMachine\Root ## Install into Trusted Root
Echo ""
Echo "Please remember to install into IIS and set the bindings for SSL and attach to this cert."
3 Likes
This was very helpful - thanks for posting Clint!
In case others run into this, I had to make a few changes:
- For a non-domain joined server, I had to change the $dnsname parameter setter to remove “+”.“+$env:USERDNSDOMAIN”, which in my case, was appending a dot “.” to the subject name alternative field without a domain and keeping the certificate from working. FYI, the web version of Epicor worked with the dot, but the admin console & full client would not function.
- I added the following parameter & values “-KeyUsage DigitalSignature, CertSign, CRLSign”.
- I changed the HashAlgorithm parameter to “SHA512”.
I’m not sure if changes #2 & #3 were required, but I had tried them before discovering the issue in #1, and change #2 was specifically listed as a requirement in the stackoverflow post I found (ssl - ERR_SSL_KEY_USAGE_INCOMPATIBLE error Google Chrome—This site can't be reached might be temporarily down or it may have moved permanently to a new web - Stack Overflow).
In case others aren’t familiar with the install after running the script, I took roughly the following steps:
- Added the new cert to the IIS site bindings.
- Restarted IIS.
- Added the cert to the Kinetic instance in the admin console.
- Added the cert to the client’s trusted root folder.
1 Like
We saw this first with our Wireless Warehouse clients and then Chrome desktop. A trusted cert, in our case - Let’s Encrypt, also makes this error go away.
1 Like
Sorry, I didn’t think on using this for non-domain joined, but you are correct you would need to alter this script to provide for that editing the $dnsname parameter. It must match for proper working. Mark provides the simplest solution using Let’s Encrypt. I provided this as I do use for internal self-signed cert generations within the internal domain and it works every time 
1 Like
Thank you both guys @CSmith & @Chris Both of your posts were a lot of help for me, now I can access the server and Kinetic.
Well, a non-domain joined server is certainly an edge use case, so it’s not a surprise you didn’t account for that!
Thanks for posting your code. I presume it would have worked without changes 2&3, but even so, your code (knowledge) was about 99% of the solution.
RE Let’s Encrypt (or any other certificate authority) - yes, that’s the solution for almost any normal business or enterprise use case and our posts shouldn’t be mistaken for recommending a self-signed certificate in lieu of CA’s cert (in most circumstances).
2 Likes
Except for SaaS. 
1 Like
Here is updated code for just SERVERNAME servers and creating self-signed SSL cert:
param (
[Parameter()]
[string]$certname="SERVERNAME", ## Identify the Host this cert is being generated for if not supplied.
[Parameter()]
[string]$dnsname="SERVERNAME" , ## Build a fqdn we hope if one is not supplied.
[Parameter()]
[string]$pwd = "Please set a password!",
[Parameter()]
[string]$path = "C:\certs" ## Default path to store generated certificate(s)
)
$dnsname = $($dnsname).ToLower()
$mypwd = ConvertTo-SecureString -String $pwd -Force -AsPlainText ## Private Key password
$cert = New-SelfSignedCertificate -Subject "CN=$certname" -CertStoreLocation "Cert:\localmachine\My" -KeyExportPolicy Exportable -KeySpec Signature -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256 -DnsName $dnsname -NotAfter (Get-Date).AddYears(2)
Export-Certificate -Cert $cert -FilePath "$path\lm_$certname.cer" ## Specify your preferred location
Export-PfxCertificate -Cert $cert -FilePath "$path\lm_$certname.pfx" -Password $mypwd ## Specify your preferred location
$certfile = (Get-ChildItem -Path "$path\lm_$certname.cer")
$certfile | Import-Certificate -CertStoreLocation cert:\LocalMachine\Root ## Install into Trusted Root
Echo ""
Echo "Please remember to install into IIS and set the bindings for SSL and attach to this cert."
2 Likes