I recently changed my IDE from VS 2019 to 2022 and I have not been able to successfully debug an SSL web site without receiving the popup message:
This project is configured to use SSL. To avoid SSL warnings in the browser you can choose to trust the self-signed certificate that IIS Express has generated. Would you like to trust the IIS Express SSL certificate?
After clicking Yes, the following message pops up:
Adding the certificate to the Trusted Root Certificates store failed with the following error: Access is denied.
After doing some research I ran the following command in an administrative prompt:
dotnet dev-certs https --clean
dotnet dev-certs https --trust -v
This resulted in the following:
An error has occurred while trusting the certificate: Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicException: Access is denied.
at Internal.Cryptography.Pal.StorePal.Add(ICertificatePal certificate)
at System.Security.Cryptography.X509Certificates.X509Store.Add(X509Certificate2 certificate)
at Microsoft.AspNetCore.Certificates.Generation.WindowsCertificateManager.TrustCertificateCore(X509Certificate2 certificate)
at Microsoft.AspNetCore.Certificates.Generation.CertificateManager.TrustCertificate(X509Certificate2 certificate).
There was an error trusting HTTPS developer certificate.
So far, I have tried importing the localhost certificate directly into the Trusted Root Certification Authorities, changing permission on the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder, uninstalling IIS Express and repairing, and uninstalling and reinstalling VS 2022. So far nothing has worked, not sure what to try from here?
For people seeing this post and having the same issue. I 'fixed' this by doing the following:
Go to your Current User certificates store and click the Personal and then the Certificates folder. If you can see there a localhost certificate where the friendly name is something like IIS Express Development Certificate then try to move that certificate to the Trusted Root Certification Authorities --> Certificates folder.
If you get an Access Denied error then try to set the Physical certificate stores checkbox, as per this post: The certificate cannot be pasted into the Trusted Root Certification Authorities store. Access is denied, under (View --> Options), make sure you selected the root certificates file to see the View/Options menu.
Repeat the above steps also for the Local Computer certificates. For some reason sometimes my localhost certificate was stored under Current User and sometimes under Local Computer.
When starting the application the following 'error' should have dissapeard:
This project is configured to use SSL. To avoid SSL warnings in the
browser you can choose to trust the self-signed certificate that IIS
Express has generated. Would you like to trust the IIS Express SSL
certificate?
Though, in my case I got the ERR_CONNECTION_RESET error after doing the above. To fix this I had to manually add the localhost port certificate as per this post: https://stackoverflow.com/a/68804745/3242154
After doing the above it generated another certificate in my personal certificate folder for the specified port, I once again had to repeat steps 1-3 (depending in which certificates store it was created), then it finally worked without problems.
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´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 am in a process of generating an SSL cert for a domain name.
What I have done:
Went to the IIS management > Server Certificates and clicked on Create Request. This generated a *.com file with a hash inside it that I submitted to the GoDaddy.
From GoDaddy I got back a zip with two files: *.crt and *.p7b
I exported the certificate to a *.cer file and uploaded it to Azure, but when I try to deploy the cloud project I get an error:
Certificate with thumbprint associated with HTTPS input endpoint
does not contain private key
After reading similar issues on the Internet, I understand that my *.cer file doesnt contain the private key.
My problem is that no matter how I try to export it to a *.PFX, the PFX option is always disabled in the cert export wizard.
Also not sure if it is related, but when I Click on Complete Certificate Request in IIS and select the cert that I got from GoDaddy. I get an error:
Cannot find the certificate request that is associated with this
certificate file. A certificate request must be completed on the
computer where the request was created.
You will not have the option of exporting from IIS or exporting to PFX from Certificate Manager if you do not do the IIS "Create Certificate Request" and "Complete Certificate Request" from the same machine.
That was my problem. I did these two steps from two different machines.
I had to create a new request (in IIS), go to GoDaddy, rekey my certificate, download the new certificate, and then complete the request (in IIS).
This turned out to be something completely idiotic, as usual messed up by Microsoft.
The process of creating a cert for a domain is that you need to use [Create Certificate Request] in IIS.
Then send the created hash to the Authority and use the [Complete Certificate Request] in IIS where you provide the cert given to you by the Authority. This will install the cert into your local IIS
After the cert is installed you need to right click on it and do an export to a *.PFX file. The PFX file now can be uploaded to Azure or any other hosting...
The processes could have been very simple, if Microsoft didn't make sure to screw it up.
The thing is that when you click on [Complete Certificate Request], the file open dialog has a file type of *.CER, but this is wrong because you need to provide *.CRT!!! The solution is to change the file type select to All Files *.* and chose the *.CRT file provided by the Authority.
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?