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.
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.
Using: Chrome 67.0.3396.99
Our webserver implements X.509 client authentication. The certificates are offered through the PKCS#11 interface; we connect a smartcard (in this case: Yubikey 4), the browser prompts for the certificate selection and PIN.
We disconnected the smartcard and visited the authenticated domain (say, localhost:8000) to observe the behavior of the webserver (in a local development environment).
The webserver correctly refused to serve the request.
However, Chrome now does never send anymore the certificates while visiting localhost:8000, even if the smartcard is connected.
The following did not resolve the problem:
Clearing all site data through the developer console;
Resettting site preferences to their defaults (through chrome://settings/content/siteDetails?);
Rebuilding the webserver.
Any pointer where I can clear this state from Chrome would be greatly appreciated. As a temporary fix, we run the server at a different port but this is not an option on the long term. As this scenario is very plausible to also happen in production.
I have a ClearOs Linux server which, amongst other things, runs a CUPS print server. Installing CUPS makes an admin interface available via https protocol.
Every time I connect to this admin server, Chrome (and IE) warns me the certificate is invalid, and I have to click twice more to go through to the site.
I would like to tell Chrome to trust this certificate. I have Googled how to do this, and tried 3 or 4 different recipes - none of them seem to have worked (the certificate is still not trusted). I have tried the following:
Connect to the site via IE running as Administrator, click on the invalid certificate flash next to the url, view certificate, install certificate, choose Trusted Root Certificate store, and install it. I also tried the Personal store and the Trusted publishers store.
Connect to the site via Chrome, click on the certificate and export it, do Settings/Advanced/Manage certificates, and import it into the store (again, I tried Trusted Root and Personal stores).
I also tried some other instructions which said to start by running "MMC" from the Windows Start button - but typing MMC only offers me Hyper-V manager and Sql Server 2017 Configuration Manager - not the management console expected.
I have read Getting Chrome to accept self-signed localhost certificate here, and tried everything there that applies to Windows 10, but nothing works.
Enter “chrome://flags/#allow-insecure-localhost” in your chrome browser and “Allow invalid certificates for resources loaded from localhost.” to bypass the security warning about your self signed certificate.
We are trying to sign a Windows 8.1 Store application with a corporate certificate obtained from Symantec. The certificate was originally ordered for Windows Phone 8 application signing, but the same certificate should work for Windows 8.1 apps also.
On a fresh Hello World -project, when we try to choose the certificate from the manifest designer in Visual Studio 2013, an error message is given: "The Manifest Designer could not import the certificate. The certificate you selected is not valid for signing because it is either expired or has another issue. For more information, see http://go.microsoft.com/fwlink/?LinkId=241478."
The certificate is most certainly not expired. On the "another issue" angle, a common suggestion for a possible cause for this issue was a publisher name mismatch between the certificate and the application, but that has been ruled out. If we skip some signing checks by adding a EnableSigningChecks=false to the .csproj file, we can sign the app, but then another error is given by PowerShell when trying to install the application: "Error: The certificate can't have the following extended key usage: 2.16.840.1.113733.1.8.52.1." Only the Code Signing and Lifetime Signing EKUs are allowed."
We asked for help on this issue from Symantec and Microsoft, but they didn't know how to help with this issue.
Has anybody encountered a similar issue with signing their apps? Is there a solution to this problem?
This issue looks to be the same as in Choosing a certificate for a Windows Store application via the package.appxmanifest, where the solution was to get a new certificate. Is the only thing we can do to just buy a new certificate?
I'm developing a Chrome App, which connects to the server over SSL. Of course, the certificate is self-signed.
In the Chrome browser, it's not a problem because Chrome opens a security warning page. If user chooses to continue to the website, it goes on to the remote page. However, in the Chrome Apps, it doesn't give such a warning page asking user whether to go on or not. Instead, a connection error is thrown out in the console.
To workaround this problem, the user has to connect to the page in the browser once and accepts the certificate, and then he/she could proceed in the Chrome Apps.
I'm wondering how to deal with this issue in the Chrome Apps directly?
If server uses self signed certificate then there's nothing you can do.
There are two other ways though, which requires server side certificate changes
and depending on those changes user may or may not have to do some settings in browser
Update the server with a Trusted CA issued certificate.
This does not require user to do any setting.
Examples for trusted CAs are GoDaddy, VeriSign etc,.
You can check the list of Trusted CAs in chrome://settings -> HTTPS/SSL -> Manage certificates -> Trusted Root Certificate Authorities
Update the server with a any other CA issued certificate.
Then provide a way for user to download the certificate and then user has to install/import it in his/her system/PC
Once certificates is installed or imported, you can check chrome://settings -> HTTPS/SSL -> Manage certificates -> Trusted Root Certificate Authorities to confirm that its installed into "Trusted Root certificates" folder. Only if certificate is imported into this folder there will be no errors in console for SSL connections.
Of course if you do not want do all this then there is a workaround as you mentioned to tell user to connect to the page in the browser once and accepts the certificate, and then he/she could proceed in the Chrome Apps
http://www.startssl.com/?app=1 provides free SSL certificates. Try having your customers get one of those instead of training your users to accept insecure connections. Or put the insecure connection over http:, which declares the intention to be insecure.