When I am try to connect the ROS using Realm Studio its says "The servers certificate could not be trusted"
Below is the screen-print :
I faced similar issue as you. But after reading Realm Studio does not trust SSL certificate of Realm Cloud on Linux #898 issue
Clicking "Reconnect, trusting the certificate" reloads the window but the same error is shown, endlessly. This was fixed with #905 but the issue of not automatically trusting the Realm Cloud certificate persists.
Users can now (once again) choose to trust the a certificate, but the issue remains that Studio does not automatically trust the Realm Cloud certificates of Realm Cloud.
I upgraded the realm studio to version 2.7.0 and attempted to reconnect. It worked.
Related
I have an ASP.NET website that is hosted on a client's web-server, which I used to be able to publish directly from Visual Studio with Web One Click Publish. The connection was made over FTPS, so would connect to the server's IP address on port 21; i.e. ftps://101.102.103.104:21.
However, after a recent update to the SSL cert on the server, I can no longer publish to the server from VS - I get the error below when testing the connection or attempting to publish the files:
The workaround I've got is to publish to a local folder and then connect with FileZilla to push the files up. The credentials I use are the same in FileZilla, and that doesn't have any issues with making the connection or uploading the files. So there appears to be an issue with Visual Studio publishing over FTPS with this new cert in place.
One initial difference I noticed with deploying via FileZilla was that upon initial connection, I would get a warning about the certificate mismatching the site name - but that was only when connecting by IP address. If I used the server name (which has the same domain as the wildcard cert on the server), it didn't display that certificate popup. Unfortunately, using the server-name in the VS publish settings still gave the same error.
While I was grasping at straws for a fix, I tried connecting on port 990 to see if I could use implicit SSL (a few articles mentioned this as an option), but this didn't work - I'm not sure if that port is blocked at the firewall or if there's just no service listening, but I can't telnet to the server on port 990.
I don't believe this is a limitation of Visual Studio as it was working before. Possibly our IT guys made some server-config changes at the same time as they applied the certificate? Has anyone else encountered this and were you able to resolve the issue?
So after some further digging, I found a Visual Studio problem ticket from January 2018 that indicates FTP publishing doesn't support TLS 1.2:
https://developercommunity.visualstudio.com/content/problem/190065/unable-to-publish-web-app-via-ftp-over-tls-1112.html
From checking the FTP connection to the web-server from FileZilla, it appears this requires a TLS1.2 connection. Therefore I assume that when the new certificate was applied, the TLS1.0 protocol was disabled on the server by IT, and that led to the FTP connection failing.
Hopefully if anyone else runs into this issue, they'll benefit from the knowledge that TLS1.2 is not currently supported in Visual Studio FTP publish (as at version 15.7.4).
UPDATE:
Can confirm that Visual Studio 2019 (v16.1.1) does support FTPS publishing using TLS1.2
I have an old Flex application deployed in client machine. Now the certificate of the original application is expired. I purchased a new license from Godaddy and created a new AIR installer for my customers.
Now the problem is the new installer while running in Windows is giving the error below. The message below is not exact from the application but this is what it means:
The application cannot be installed due to a certificate problem. The
certificate does not match the installed application certificate, does
not support application upgrades, or is invalid. Please contact the
application author.
Now my question is, do I need to use the expired certificate and resign it and reuse it. Can't I use a new certificate. My ultimate goal is my customers should me able to install the application and that should override/update the old application.
I've tried to deploy a small website (ASP.NET) which is using an MS ACCESS 2010 db. Deploying the website on the server I get the following error:
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
Connectionstring used : Provider=Microsoft.ACE.OLEDB.12.0; Data Source=path-to-db
MS Office is not installed on the server and neither is the Access Database engine. The website is runnin in a shared hosting environment, so I am not able to install office on that server, so may I somehow deploy the provider by dll's?
Is it possible to deploy the drivers needed for ASP.Net to connect to the database without having to run an installation on the server. As this is in a shared hosting environment, I am not able to install anything. Only fileupload by ftp.
Open IIS, navigate to Application Pools, find the appPool for your website, right click, advanced settings, set "Enable 32-Bit Applications" to true.
Looking around, this has nothing to do with Office. If you're only using Access as the database, then you don't need to install it. Info here: http://www.mytechsupport.ca/forums/index.php?topic=11237.0
I found this StackOverflow thread with the same error you did so it sounds like it might be the same issue. Microsoft.ACE.OLEDB.12.0 provider is not registered
If its running windows then look through that thread and see if the 64-bit issue is the problem. I've had this same issue before and its apparently quite common. You may need to e-mail whoever for support on your server.
Is it running Linux? If it is running linux then the issue might be just an entire lack of the driver to connect to Access databases. If this is the case I would e-mail your support and ask them if they can install the proper drivers for you. Info here: http://nixcraft.com/databases-servers/11878-connect-microsoft-access-database-php-linux-server.html
My question is: why does a dev site work when the project is run in Visual Studio 2010, but not when served from IIS on the same PC?
I am trying to set up a dev copy of a client's site. On startup, the site makes a connection to a remote database server. The connection uses WCF and a SSL certificate to secure it. When I installed the site on my PC, following instructions, I installed a Cert Chain into the "Trusted Root Certification Authorities" and added registry keys and host entries to resolve connections to the remote service.
When I open the solution in Visual Studio 2010 on my PC and run it in the built-in ASP.NET dev server, it works -- my workstation connects to the remote service via SSL on a custom port (444) and the dev site queries for data successfully from the service. All of this is handled by a DLL provided with the project, and is outside my scope of work. I was briefed up front that the connection was very finicky about the SSL cert, system clock time agreement between the two machines, etc. and it took me a few tries to get it to work.
However, when I run the site in my local IIS (Windows 7, IIS 7.5) the site cannot connect to the remote service; the service won't accept the SSL connection. The startup code throws an exception when this happens, preventing the site from loading further.
Everything else seems to work fine: the only wrinkle is that VS requires a 32-bit version of the secure connection DLL while IIS on Windows 7 requires a 64-bit version. Both were provided to me and I swap them as required.
Per the comment, the answer is: check that the Cert Chain (to trust the SSL certificate used by the WCF connection) is installed to Local Machine (so that IIS sees it), not just to Current User (account used by Visual Studio).
Disclaimer: I'm an Air newbie (about 20 minutes in to this experiment).
I have a demo application using Adobe Air that accesses my own SSL web service that uses a self-signed certificate. In .NET clients, I can explicitly handle (and ignore) certificate warnings and suppress them via the ServicePointManager.ServerCertificateValidationCallback. Does anything similar exist in Air? I've examined the URLRequest and URLLoader classes but haven't found anything.
If you are using Windows XP install the untrusted or unknown certificate in your Trusted Root Certificate Authorities. You can install the certificate from Internet Explorer while accessing your site.
There is a registered bug On Vista and Windows 7. The bug is not resolved yet.
So only solution (without changing server behaviour) is to add your self-signed certificate to system's Trusted Root.
There is additional info about Secure client sockets in AIR and SecureSocket class.