That is expected behavior for a self-signed cert.
Anyone get it installed into Android for EKW?
Cert created with powershell works, cert created in IIS - does not
THis is where it is created
and the error is mentioned here: ERR_SSL_KEY_USAGE_INCOMPATIBLE
It is different from the error you have until install in trusted storage.
1 Like
Here another key usage is mentioned - Digital Signature
You Have 2 options to fi this error, one is to use a Certificate signed by a trusted CA (LetsEncrypt,Sectio,etc.)
The other option is to generate you own certificate and making sure to apply the correct Key usages.
Software:
- OpenSSL for Windows: Binaries - OpenSSLWiki
Steps:
1. Installation:
- Download and install the latest version of OpenSSL for Windows.
- Extract the downloaded file to a location, e.g.,
C:\OpenSSL.
2. Open Command Prompt:
- Open a command prompt window with administrator privileges.
3. Navigate to the Bin Directory:
- Use the
cdcommand to navigate to the OpenSSLbindirectory, e.g.,cd C:\OpenSSL\bin.
4. Generate Private Key:
- Run the following command, replacing
axelgaard.keywith your desired filename and entering a secure password when prompted:
openssl genrsa -aes256 -out your_key_filename.key 2048
5. Generate Certificate Signing Request (CSR):
- Replace placeholders with your information and desired key usages/extended key usages in the following command:
openssl req -new -key your_key_filename.key -out your_csr_filename.csr -subj "/C=your_country/ST=your_state/L=your_city/O=your_organization/OU=your_unit/CN=your_domain.com" -addext "keyUsage=digitalSignature,keyCertSign,cRLSign,keyEncipherment,dataEncipherment" -addext "extendedKeyUsage=serverAuth,clientAuth"
6. Generate Self-Signed Certificate:
- Run the following command, replacing
your_key_filename,your_csr_filename, andyour_cert_filenamewith your chosen names:
openssl x509 -req -days 3650 -copy_extensions=copyall -in your_csr_filename.csr -signkey your_key_filename.key -out your_cert_filename.crt
7. Verify Certificate:
- Use the following command to view the certificate information and ensure the desired key usages/extended key usages are present:
openssl x509 -in your_cert_filename.crt -text -noout
8. Apply Certificate:
- Follow the specific instructions for your application or server on how to import the generated certificate (e.g.,
your_cert_filename.crt) and private key (e.g.,your_key_filename.key).
9. Distribute Certificate:
- If applicable, distribute the certificate to trusted clients for authentication purposes.
1 Like
This happened to us about a week ago. Here is the fix that I used both chrome and edge. I would call it a temporary for now until we get the cert corrected or an actual cert. Been pushing it off.
1 Like
We just upgraded to 2023.2.9 and are now having this issue with MS Edge, but…
I can access EDD on our Dev server locally and from a workstation using MS Edge but I cannot access EDD on our Production server locally or using the same workstation using Edge. Both certificates were generated the same way from Epicor and stored in trusted root and bindings in IIS. The main difference is that I can access Dev using HTTP or HTTPS where as I can only access Production EDD with HTTPS. So I am wondering if it is more of an issue with a setting in IIS and/or an issue with Epicor. I am not that familiar with IIS that I can figure out what that setting is.
Adding the Registry key for Edge as @mmcwilliams mentioned worked for me to be able to access EDD on our Productions server with Edge.
It’s more of a security posture issue. Hopefully, we’re not using Production Data in the Dev instance. If so, then we are passing user credentials in the clear. If people are reusing their Kinetic and Windows passwords, they can be easily sniffed out by a threat actor. I know we feel “safe” in our networks but owners of Barracuda, CISCO, FortiNET, Progress, and most recently Ivanti edge devices are learning why it’s important to encrypt your internal networks.
Having a trusted certificate is really the best way forward. It makes working with outside services like PowerBI, Automation Studio, Azure, etc. possible. I have even noticed that both SQL Server Management Studio or Azure Data Services are starting to warn us if our SQL Servers don’t have a valid cert.
The next challenge with certs will be when Google reduces the lifetime to just over 90 days. Imagine having to have to distribute self-signed certs every quarter. There are ways to handle this like using https://certifytheweb.com or use almost free services within Azure.
It’s time to get ready for the future.
2 Likes
Issue for self signed certificates is the settings that Epicor uses when generating the certificate. It is Missing a Key Usage that Browsers are now checking for to make sure that the certificate is being used in the correct way.
@olga suggests that it may work with version of Kinetic higher than mine. I’m not sure if more up-to-date users have tried the most recent version to see if that is fixed or not. It’s definitely not working in K2021.2.
Mark, actually that wasn’t my point. I am not advocating that we should just go back to plain HTTP for all and throw caution to the wind. What I was trying to point out is that in my systems I can use the same workstation with MS Edge to access the two environments using HTTPS and using Certificates that were generated the same way/time, why does one environment work while the other throws the error ‘ERR_SSL_KEY_USAGE_INCOMPATIBLE’. The only differences between the two are the settings of IIS. So I am wondering if someone knows of a setting in IIS that demands the browser check for the ‘Missing Key Usage’ or is it embedded in Epicor.
Setting the lifetime to 90 days is like putting four deadbolts on your front door to only leave the window open. This will only hinder the users and prevent the honest thief’s, if someone is determined to get in they don’t have to use the front door.
The two environments are the exact same version of Kinetic?
Not sure I get the analogy.
The reason for the 90 days is that most clients do a poor job of certificate revocation. Reducing the certificate from 10 years to 2 years and now to 90 days ages out compromised certificates quicker. The same is true for API keys. The more often you roll them, the less value they get on the underground market.
As far as I have seen, this is a Chrome issue. One can imagine that letting webservers dictate client security might not go well. For more information, see the link that Olga posted above:
@Mark_Wonsil , yes both are the same 11.2.400.09.
My analogy is that there are many other ways that hackers can get access to your data and to what point do we secure the systems so much that the security measures become a hinderance and cause people to not implement any security. I am on Prem and so if a hacker gets access to my network a Certificate will not stop them from getting access to my data.
Encrypting the network data will certainly help slow them down and should be a requirement. For Cloud users, I would certainly agree with shortening the life of Certificates. But, look at Password usage, the more conditions you put on password usage and complexity the more a user will find a way to simplify the password and reuse it everywhere.
No it is also an issue with MS Edge. Currently FireFox still works though
Mark means Chromium not just Chrome
If you inspect the certs, do they both have the exact same Key Usage?
Me too.
Very true. The purpose of the certificate is to improve identity between clients and servers and to encrypt traffic between them. You bring up an excellent point: it’s all about protecting important data. Data is at risk when it moves so that’s why having certs is only a part of the solution.
100 Percent! The solution to put more conditions on passwords has already been rejected by the person who came up with those rules. Passwords/Basic-Authentication needs to die. They were invented in the 1960s and are too easy to break. That’s why passwordless (but still muti-factor) is a much better way to go.
That leads me to believe it’s not an IIS issue. Chrome is cracking down and FF will too eventually since they are pretty security minded too.
Yes they do
Here is from Chrome forum about this flag
https://support.google.com/chrome/thread/239508594/err-ssl-key-usage-incompatible-error-in-chrome-but-not-edge-for-all-google-sites-and-some-others?hl=en
I don’t understand how it affect one cert and not another then
1 Like
What happens if your clear the browser cache for the site that works?
I actually had to restart browser completely and then it would acknowledge if the cert was in the Trusted Roots, but not during the same PID session.