I moved recently my app to a scalable gear, I was using a custom domain with a startcom certificate and it worked fine.
Now Android devices mark the certificate as invalid, I was googling and the problem occurs if you don't configure the ssl chain properly. I have configured it right but I did it one more time, however the problem remains.
According to this ssl checker https://cryptoreport.websecurity.symantec.com/checker/ the chain is not sended and Android continue showing https://refly.xyz as invalid.
It's very possible that you have not combined your ssl certificate & chain certificate correctly. You need to combine them into the same file (ssl certificate first i believe) and then upload that as your certificate, and your key file. Don't upload anything into the chain form field.
Related
I'm using powershell New-SelfSignedCertificate to create a certificate and import into trusted root for a .netcore project.
It has been working fine, but has recently stopped, certificate doesn't expire until 2024.
I'm on Chrome 106.
Any ideas on why it would stop and how to fix?
Yes, Chrome has introduced its own certificate root store. They say this happened back in Chrome 105 but we've only started experiencing problems since Chrome 106 on enterprise environment.
On Windows you may disable this new feature via registry:
Create a REG_DWORD value ChromeRootStoreEnabled = 0 at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
Restart Chrome
Taken from chromeenterprise. But don't forget that disabling this feature without understanding what you do may be a security risk - not a big one in this case but anyway.
The docs actually state that the new root store takes locally trusted certificates into account:
The Chrome Certificate Verifier considers locally-managed certificates during the certificate verification process. This means if an enterprise distributes a root CA certificate as trusted to its users (for example, by a Windows Group Policy Object), it will be considered trusted in Chrome.
We use our own CA to sign test websites HTTPS certificates on enterprise environment. So we seemingly must not have been affected. But even though everyone on the dev team has our CA installed in trusted root - we still face this issue. I'm not sure whether it's a bug or there is something else we need to know about which CAs are accepted and which are not.
Update 2022-10-24
I found out that there is another local enterprise CA apart from out team's one. Сertificates issued by that CA are accepted by Chrome without disabling the new root store - so Chrome obviously does not ignore locally trusted certificates.
After some trial-and-error I've figured out that the problem was not about the CA certs - but about the endpoint CA-signed certificates. The old now-rejected test certificate contains these properties:
Basic Constraints: subject = not a CA, path length = 0
Key Usage: Digital Signature, Key Encipherment
Extended Key Usage: TLS Server, TLS Client + 9 internal custom OIDs
Subject Alternative Name: localhost + around 30 test websites DNS names in various domains
Removing the Basic Constraints property made Chrome finally accept the cert.
So there have been more changes to certificate validation procedure apart from the new root store. By far I haven't found any documentation about what exactly they've also changed. And AFAIK Basic Constraints is an absolutely fine property to have even in a non-CA certificate, so it looks like a bug in Chrome to me.
I am trying to access a website that allows SSL logon. I want to log in to the site using different username and credentials. The problem is that chrome always picks up the certificate by default. Is there any way to stop this.
The recommendation would be to use the 'Incognito tab' instead of the usual tab that will not save your SSL certificate.
I'm creating an API using node js and express. As we are moving towards production, I decided to encrypt the api using ssl, (simply adding the require 'https' option and creating the requires key and cert files using openssl).
I want to continue working on the API using postman (chrome plugin), so to enable me to do this, I visited the API using Chrome, saved the cert for the API to disk and then imported that cert file (cer format) to the "personal" certificate store in Chrome. So far, so simple.
I was then able to start using the API over ssl as expected. Great.
Now, where it is starting to get a bit odd is that if I want to then remove that certificate from my personal certificate store in chrome, I was expecting to be able to just open up the settings - > htttps - > manage certificates and then to be able to remove the certificate, however the certificate is not visible in the list of certs. It's clearly been imported and is working, it's just not showing in the list. The machine in question is running win 10, so I also checked the certificate management console for the machine and I searched for the cert and cannot find it anywhere.
I think that this should be really simple, so where is that cert that I imported (and which is clearly imported and working) so that I can remove it?
Thanks!
So, I finally found the solution to this. From the command line start "certmgr" and from there I can see the installed certificate and remove it. Not sure why it doesn't show up when viewed from within Chrome?!
I'm using Advanced REST Client to test external API which requires me to specify
Connection: Keep-Alive. The connection fails (NO RESPONSE) and inspecting Chrome console I noticed Refused to set unsafe header "Connection" followed by net::ERR_INSECURE_RESPONSE
Is there any Chrome settings that allow me to override this? BTW, the API works when I use external tools like APIGee. I've tried Chrome CORS extension (Allow Control Allow Origin) but still unsuccessful.
The issue is that chrome is refusing to load a resource that has an invalid or expired SSL certificate. Even if you could get it to bypass that it would be a bad idea as it would make man in the middle attacks easier in your application.
My suggestion would be (if you trust the server or if it's running locally) to import that certificate to your store so it's trusted in your development environment. If the cert is expired and it's hosted locally look at the documentation on how to change the certificate or to add a self signed one (which you then also would add to your trusted sites)
How to add a self signed very to your store
For Mac
For windows
You'll have to restart chrome for it to see the certs in the store after doing this
Again, be sure you trust these certs origin as they'll be considered trusted as if a legit CA HAD issued them
I need to connect to a web service via HTTPS in my windows phone 8.0 app. It seems that there is no client SSL support from Microsoft about this issue.
I really need to know how to deal with certificates in WP8. What is the correct certificate? Which certificates need to be imported?
Scenario: I have a https endpoint: https://10.1.1.2 and when I connect there from my PC I am being prompted to view and install the certificate of the server. The certificate name "The Root CA" is being saved locally. The same certificate is installed in the mobile device w/o problems. When I open the https://10.1.1.2 from the mobile internet explorer it informs me that the web page is secure and I have to choose between close and continue the page. I am clicking continue and the https://10.1.1.2 transaction takes place. Every time I go to the same URL via the mobile internet explorer there is no warning to the end user regarding security.
According to Microsoft: In most cases, you do not have to do anything
to enable this for your Windows Phone app with the exception of using
an address that begins with the https:// protocol scheme. Windows
Phone then examines the certificate that is returned by the web
service, and if the certificate is from one of the trusted authorities
listed in SSL root certificates for Windows Phone OS 7.1, the Windows
Phone app platform then uses the certificate in conjunction with the
web service to encrypt all further communication, including the
exchange of the authentication credentials as described previously.
Although you can install trusted certificates on the Windows Phone, in
the current release, the Windows Phone app platform does not expose
those certificates’ values to apps. As a result, in the current
release, you cannot implement mutual authentication scenarios –
scenarios in which the client sends its own certificates to the web
service in addition to receiving one -- using certificates installed
in the root store.
So, is this procedure OK? I cannot use one of the certificate authorities that Microsoft
trusts by default. Do I need code?
Self signed certificate cannot be used and it does not automatically fetch data without intervention.
First of all, when testing your SSL connection through mobile IE, it appears from my testing that by pressing continue you are adding an exception to IE, not installing any certificates or getting the exception to apply phone-wide.
Secondly, using self-signed certificates on WP8 appears to be severely limited by the fact that any cert chain that does not use a built-in root CA will generate a failed certificate validation in your code. See the MSDN blog entry at http://blogs.msdn.com/b/davidhardin/archive/2010/12/30/wp7-and-self-signed-ssl-certificates.aspx
Where he states "You can implement your own certificate authority using Microsoft Certificate Services but you’ll still need a certificate from one of the phone’s certificate authorities to chain your certificate authority to."
The only "solution" I've seen posted is to effectively ignore all certificate warnings - which is no solution at all.