I'm selfhosting a NancyFx service with Owin (on intranet from a Windows 8 machine) and it works fine. Trying to switch to HTTPS but have run into problems.
I have:
Created self-signed root CA
Created exchange-cert using above CA (CN=mycomputer)
Exported public key of CA and installed on client-machine
Used netsh to add urlacl to https://+:5001
Used netsh to add sslcert with thumb-hash etc.
The service-host looks to start allright on my address, https://mycomputer:5001, but when I try to access this address I first get the warning about unsecure connection (which I shouldn't if I have installed the public key CA-cert right?) and when continuing anyway I get a "service not available"-respons.
Any hints to what could be wrong?
Do I have to config Nancy/Owin to use the certificate somehow or is it enough to have it attached to the endpoint with netsh?
I've got it working. I've found it useful to have a number of checks in the process.
CHECK1 - Cert import ok:
- After you install the cert on the machine run certutil -store MY
- You shoudle see the cert details there (sha/user created/name etc)
- If not STOP. You probably imported into the user store (or the cert is invalid). You MUST start with empty mmc and import certificates for the MACHINE.
CHECK2 - url is added to urlacl list in netsh
- After you add the uri to acl run netsh http show urlacl
- If your uri / port is not listed STOP. The url isn't added correctly.
CHECK3 - ssl is bound to urlacl
- After running the add sslcert command run netsh http show sslcert
- If your port/sha combination is not listed then check the sha has no spaces / appid is unique / app id + braces surrounded by quotes (if executing from PS)
Hope it helps. I created the above after 6 hours of head banging. It now works!
Related
Pulling my hair out here. Yesterday I set up an SSL Certificate in IIS10. This is the process I followed:
In IIS, under Server Certificates complete Create Certificate Request (generated server.csr & server.key)
Go to sslforfree.com and start "create certificate" process.
Enter Static IP in Domain box
In Validity, choose paste Existing CSR (paste in contents of server.csr)
Select free 90 day certificate
Choose HTTP file upload and add auth file to virtual share in IIS.
Verified OK.
Download certificate
Back in IIS, select "Complete Certificate Request"
Browse to and select "certificate.crt" file.
Give it a friendly name etc, and save.
Browse to website under sites in IIS, and select Bindings. Choose the IP of the server, the incoming Port, and the newly imported SSL certificate.
Back in sslforfree, check the installation.
Everything all good
So everything was working beautifully, could see the certificate in the browser etc, job done.
Now come to today, and the server is actively refusing requests. Go back to check the installation of my SSL on sslforfree, and it's no longer found. Tried removing and re-adding, but nothing I do seems to get the SSL to be visible.
It's not that the certificate is refused, the browser doesn't even think it's there. Why would IIS suddenly stop sharing the certificate? I am totally stumped.
EDIT
As per the advice below, I set up a DNS name with CloudFlare and pointed it at my server.
I Set up the bindings in IIS to link to the new hostname and removed the old certificate (one for port 443 and this one for port 4443 which the API runs on):
Ports 80, 443 and 4443 are all port-forwarded on the router to my server:
I then downloaded Win-ACME and successfully created the Let's Encrypt certificate, and the renewal task created in Task Scheduler.
SSL Cert now shows in Bindings:
SSL Certificate appears to be all good:
...but when I go to the site, using the new domain name. Same problem... no certificate:
So I'm not sure what the problem is here...
This issue may happens when the imported cert does not have a private key associated. solution would be to import the .CER file to your system(from where certificate is requested) personel store and export it with private key. Then copy the .pfx file to required server and import it from server certificate option under IIS.
And you can refer to this link: The Whole Story of "Server Certificate Disappears in IIS 7/7.5/8/8.5/10.0 After Installing It! Why!".
Thanks to Lex Li, I was able to dig around with Jexus Manager, and IIS Crypto to work out what was wrong.
Seems having TLS 1.2 an TLS 1.3 enabled on my machine at the same time was causing issues. Discovered this using Postman and disabling certain TLS Protocols, eventually getting it to work.
For those of you who may experience similar issues, using this application and setting it to "Best Practices" after disabling TLS 1.3 in my Registry, I finally have it working, with a certificate.
I have created a trusted certificate as follows (cleaning up potential pre-junk). During that, I got the popups telling my that a gang of crazy donkeys can do evil things if this is a root cert. The last comamnd confirms that I have a working certificate. I even ran the commands twice to verify that cleaning would produce a warning too, which it did, just as expected.
dotnet dev-certs https --clean
dotnet dev-certs https --trust
dotnet dev-certs https --verbose
I haven't imported any PFX-files as my understanding is that working in development towards a localhost instance doesn't require that. That seems to be confirmed by the information in the console letting my know that the certificate is generated properly. Running dotnet dev-certs http --check produces no warnings (no confirmation neither, it's no content in the result).
The HTTPS developer certificate was generated successfully.
A valid HTTPS certificate is already present.
Then I executed a call to my token dispencer endpoint getting a reply as expected too. It comes back from a secure HTTPS on localhost:5001/connect/token and containes all the vital parts.
{
"access_token": "eyJhbGciO...Ow7EEkA",
"expires_in": 3600,
"token_type": "Bearer",
"scope": "myapi.read"
}
What bothers me is the warning with red icon and the text Unable to verify the first certificate.
I've made sure to disable SSL checking and turned off CA Certificated (althoug I haven't added any Client Certificates in that menu. Googling gives me a bunch of hits on problems related to Ubuntu and/or MacOs but I'm based on a good old Win10 so those turned out irrelevant.
Have I misunderstood the approach all together or, possibly, confused some of the concepts? If not, what can I do to trouble-shoot it further?
I dig in to this a little.
dotnet dev-certs https --trust command just creates/makes sure a new localhost certificate (with friend name ASP.NET Core HTTPS development certificate) and puts it into the trust root store.
IIS Express server however won't use it automatically. It still uses the certificate (friend name is localhost) that is created when you run the APS.NET Core web app for the first time. If this certificate is removed from trust root store you will get the cert error.
You have a few options to address this issue.
Reset the IIS Express cert.
Switch the cert IISExpress use to the one you just created, you can retrieve it using the PowerShell command below and following this link.
Get-ChildItem -path cert:\currentUser\My | Select-Object FriendlyName, subject, Thumbprint
We received an email saying our port 5986 (WinRM?) certificates are set to expire soon and we should take action to avoid interruption.
The way i configured WinRM for TFS communication last year was like this:
Download from GitHub this PowerShell script
execute the following in the PowerShell console with Administrative permissions: ConfigureWinRM.ps1 {FQDN} https
example: ConfigureWinRM.ps1 server.tst.com https
Do i just have to rerun this again to renew? Do i need to remove the old certificate thumbprint first?
Apparently, there was a bug 4 years ago that it appears that WinRM somehow does note that the certificate has been renewed, because it continues to accept WinRM connections over HTTPS with no issues, even after the certificate referenced under WSman\Listener has expired.
i dont want conflicts to occur so i want to renew this safely, especially when we get the same notification for production.
Note: some useful commands used in that git bug report to compare replaced cert Thumbprint:
ls cert:\localmachine\my
ls wsman:\localhost\listener\listener_1305953032
Winrm enumerate winrm/config/listener
netsh http show sslcert ipport=0.0.0.0:5986
I just had to rerun the same steps again (skip step1 if script is still there from last time)
Download from GitHub this PowerShell script
execute the following in the PowerShell console with Administrative permissions:
ConfigureWinRM.ps1 servername https
Looks like the bug is not present on PSVersion 5.1.14393.3471
I ran the commands above listed in the Note and the new Thumbprint was getting displayed for all 4 of them.
restart wasnt required
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
Im creating alert using URL Health check for HTTPS in mule MMC. When I configure Http url works fine. But for HTTPS how can I achieve the health check( https://apps:8089/check), since it is secured connection, there is no option for keystore path where can I place my certificate. Obvious Alert showing me 'SSL handshake error'( Because no where i can configure the certificate) .
How can I configure HTTPS url in MMC( MMC document in Mule also says for HTTP not for HTTPS). Hopefully some way should be there .
Let me know whether it is possible or not, If possible how to achieve the same.Help will be really appreciable.
I assume you are running MMC using container such as tomcat, glassfish or jboss. All these containers use JRE/JDK(depending on what you have configured). If you are trying to invoke an HTTPS url from MMC, the relevant certificate(for the HTTPS URL) must be imported into JDK/JRE trust store so that when HTTPS url within MMC is invoked in the JVM(that is running MMC in tomcat/glassfish/jboss), the relevant certificate can be recognized.
Download the certificate from the browser(by clicking on the green bar in browser)
Use this command to import certificate:-
keytool -import -file "Path to your certificate file" -keystore "C:\Program Files\Java\jre7\lib\security\cacerts"
Once done, restart your container and try again.