for Windows 10 DESKTOP device portal, has anyone been able to successfully provision self-signed SSL certificate to device portal as per instruction found in https://learn.microsoft.com/en-us/windows/uwp/debug-test-perf/device-portal-ssl?
I only need to connect from localhost, so using the same powershell scripts from the article, I created and installed a self-signed Root CA to Trusted Root Certification Authorities store, then used it to sign SSL certificate for localhost, 127.0.0.1 and ::1. Each are exported as .pfx and provisioned to to device portal as instructed. webmanagement and the machine were restarted.
Yet, still couldn't get the 'Site not secure' page to go away on web browser.
Edge error code:
DLG-FLAGS-SEC-CERT_CN_INVALILD
Any insight is much appreciated. Thanks.
As it turned out, using 127.0.0.1 actually works, while localhost and ::1 doesn't. Also, since I'm using it in UWP C# implementation, I was suppose to add 'auto-' in front the login name in order to bypass CSRF protection. Once I did that, I can get 200 status code.
Related
I have created a self-signed certificate on IIS and added it to Trusted Root Certificates using mmc.exe and when I launch my intranet using https://ipaddress shows secure. But when I go LAN and browse for the https://ipaddress shows me not trusted. I also used on IE, which I installed the certificate but still showing not trusted. Am I missing something, please help.
Self signed certificates are not trusted by browsers as the issuer (yourself) is not a trusted Certificate Authority. However, you can trust the self signed certificate if you want by adding the particular certificate to Trusted Root Certificate store. For IE, import the certificate to the Trusted Root Certificate Authorities folder in the client machine. Note that this has to be done on all client browsers/machines to trust your certificate.
Also, there could be other reasons for not trusting the certificate, please read the error description clearly.
If you use subdomain, i.e. subdomain.domain.com, the domain administrator (IT) should provide you with a wildcard certificate.
The domain administrator generates and assign the certificate to your subdomain server, also should allow port 80 and 443 firewall rules so that users can visit the site in the intranet.
The above answered methods can be used to generate the certificate, preferably sha256 certificate. Once the certificate is provided to you, install it on your server to “Personal”, “Trusted Root Certification Authorities” and “Web Hosting”. Open the certificate to validate it installed successfully, and you can use the thumbprint to sign files, such as rdp files. To do this, on your keyboard, START + R to open the run command and enter “certlm.msc” and once the window opens, navigate to “Trusted Root Certification Authorities” and there should be the certificate that was just being imported, i.e. *.domain.com, double click to open the certificate and click on Details tab. Drag the scroll bar until the Thumbprint is visible and then click on it to revel the code. Create an rdp file to your subdomain and save it to your desired location, such as desktop. Open CMD terminal and CD to the location and enter “rdpsign /sha256 thumbprint ‘./sumdomain.domain.com.rdp’”. Done, now when you open the connection, the compute should be trusted to connect to RDP, this process is not necessary, but it is nice to see the publisher is recognized.
The benefit of having the *.domain.com certificate generated for your organisation is that users should have this certificate already installed on their PCs and when they visit your website, users would automatically see the HTTPS secure padlock for SSL certificate. The certificate would usually be generated to allow all subdomains, i.e. *.domain.com.
IIS, When setting up the HTTPS binding on your IIS settings, check the "Require Server Name Indication" and continue to browse for the certificate and select and save the settings. Also turn off Directory Browsing while you’re there. Go to SSL Settings and check on Require SSL and hit Apply and go back. To control the flow of HTTP to HTTPS when users visit your site, you can use “URL Rewrite”, install it from Microsoft and you can do the configuration, please check on https://www.ssl.com/how-to/redirect-http-to-https-with-windows-iis-10/ for the appropriate settings. Even though, this answer is out of the scope for the question, it may be helpful for anyone who look forward to configuring their intranet site. Next to checkout is the security for who accesses your site, check on AppPoolIdentity, more help on IIS7 Permissions Overview - ApplicationPoolIdentity.
I have my website https://www.MyWebSite.com running on port 433. But I also have a admin login that only are available from the office local network http://MyServer:9999/Login.aspx. Both addresses points to the same site but different bindings.
Is it possible to get the one on port 9999 to use https? I tried creating a self signed certificate in IIS but my browser still complained, even though I exported the certificate and stored it in my CA Trusted root.
So just to sum everything:
My regular site: https://MyWebSite.com <-- working fine
My admin login, only accessible via local network: http://MyServer:9999/Login.aspx works fine.
When adding a selfsigned certificate issued to "MyServer" (not MyWebSite) and add the new binding on port 9999 I though to the website but Chrome is giving me a warning NET::ERR_CERT_COMMON_NAME_INVALID, even though the cert is Issued To MyServer and are trusted
Is it possible to get the one on port 9999 to use https?
yes it is possible to setup another port with selfsigned
certificate.
Normally Selfsigned certificate will have fully qualified machine name
e.g. machinename.subdomain.domain so you have to browse using https://machinename.subdomain.domain:9999/
Please double check what error you are running into ,In chrome
Your connection is not private
Attackers might be trying to steal your information from in08706523d (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
in IE,you may get
There is a problem with this website’s security certificate.
The security certificate presented by this website was issued for a different website's address.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
In that case,assuming you have given hostname as * in IIS binding, and also installed the selfsigned certificate installed your "Root Certification Authorities " You should be able to browse to
https://machinename.subdomain.domain:9999/ without any issues
I run localhost on my Windows 8.1 (Bootcamp on Mac) and need to enable ssl.
I have already default server certificates on 127.0.0.1 and localhost.
I have the localhost one assigned to my websites on port 443.
https still returns security error so I need to work on http
My websites run on 44300 port (eg. localhost:44300)
I tried to bind the certificate to 44300, still it didn't work.
How to make my locahost to work with https? Thanks
EDIT
The certificate is issued by localhost and is within Trusted Root Certification Authorities:
Btw I followed this thread to issue the certificate for my website: Enable SSL in Visual Studio
It is probably because it is not installed in Trusted Root Certification Authorities.
Solve this by starting mmc.exe.
Then go to:
File -> Add or Remove Snap-ins -> Certificates -> Add -> Computer account -> Local computer
Expand the Personal folder and you will see your localhost certificate:
Copy this into Trusted Root Certification Authorities - Certificates
The final step is to open Internet Information Services (IIS) Manager or simply inetmgr.exe. From there go to your site, select Bindings... and Add... or Edit.... Set https and select your certificate from the drop down.
Your certificate is now trusted:
Original answer:
https://stackoverflow.com/a/48790088/3850405
Try to install Microsoft IIS Administration from https://manage.iis.net/get
it will create a certification for your local server
then use https://manage.iis.net/connect , get an Access Token and connect it
check your localhost on https https://localhost
I´m trying to solve this new problem for internal deployment and testing.
I was successful creating an Internal CA certificate, and a SSL one with it. The host is a local IIS referenced as hostname.domain. I installed the CA certificate on the host and configured the HTTPS for the site (hostname.domain) with the SSL certificate. I tested on MacOS Safari client and it could not verified the site until I installed the CA certificate in the keychain. This means that SSL Certificate and CA are working correctly for the host name…
Then I e-mailed me the CA certificate and installed in my ipad. It is showed as a profile with one certificate, Trusted.
Unfortunately Ipad´s Safari keeps telling me that cannot verify the identity of the hostname.domain, and if I continue to the page accepting it, the OTA download fails with the message “Cannot connect to hostname.domain”
Any idea of what is missing?
Thanks.
The proper way to fix this is by creating a signed certificate that is issued by a Certificate Authority that you also create for your organization. The specifics can be found on this particular answer: https://stackoverflow.com/a/22367111/71079
This command line application will help you set this up: https://github.com/deckarep/EasyCert/releases
I've tried setting up SSL for localhost running my azure web role.
What I've done is that I've created my own CA, created a client and server certificate and then installed them all in my certificate store. The server certificate is located in the local computer personal certificates, the client certificate is installed in the current user store under personal and the CA certificate is installed in trusted root certificates in both stores.
I've also configured my IIS website to use SSL and used netsh to bind the server certificate to the ip the site is running on.
However when I try to access my website through the IIS, I get an error:
HTTP Error 403.16 - Forbidden
Your client certificate is either not trusted or is invalid.
I know for a fact that the certificates I use are issued by the same CA, so I cant really see any other reason than that the IIS probably cant access my trusted root store. When I deploy my solution to azure, it works without giving me this error, so I'm positive that its a configuration issue with the local IIS that I cant work out.
Any suggestions on what could be the problem here?