Setting SSL certificate for Web Deploy agent - ssl

I have configured Web Deploy for my IIS installation on Windows Server 2008 R2.
I did this before buying a valid certificate for the domain, so it was normal to get a Visual Studio warning about self-signed certificate the first times.
However, after we bought a valid certificate for the domain, I do not know how to tell Web Deploy to use the new certificate (I publish directly to https://www.example.org). The warning is about the computer's self-signed certificate using the computer name as the host name.
The server is not in an AD domain or somewhat.
Any help? Thanks

In case you did not find the answer yet:
You have to go to the servernode. Click Security/Managment Services.
There you can select the IP-Adress for Web Deploy and the Certificate you want to use. In order to Change it you have to stop the Service.
See: https://technet.microsoft.com/en-us/library/cc770458(v=ws.10).aspx
regards
Lothar

It is 2020, and I also ran into this problem. The solution that worked for me is this:
Open IIS Manager
Click on your server on the left hand side
Open the Management group
Open "Management Service"
If the service is currently running, click stop on the right hand side. This enables the configuration of the Management Service.
In the "Connections" section, there is a dropdown for SSL Certificate
Choose the appropriate certificate
Start "Management Service" once again by clicking on the start button on the right hand side.

Related

Publishing to IIS with WebDeploy from Visual Studio certificate error

I'm attempting to move to a new server. The new server is Windows 2022 with IIS 10. I've added my domain, lets use example.com, and added a trusted ssl certificate to it. The site is reachable and only accepts secure connections. I pinged the domain and the ip matches the server.
This is the certificate information when you visit the webpage.
My publish settings are set to that domain for all applications that I'm publishing on this server:
https://example.com:8172/MsDeploy.axd
When I go to publish though, it's giving me a message about an invalid certificate.
It's not seeing the certificate that I have for for mydomain.com. Does WebDeploy use a different certificate when publishing? I thought it would use the domain that I'm connecting to domain.
Anyone have any suggestions?

How to wire up a valid local self-signed certificate for ASP.NET Core and IIS 10 on Windows 10?

We're not using Kestrel, nor IIS Express. We use IIS for local development. Thus we can't find out any command of dotnet dev-certs to help us.
We can create a self-signed certificate in IIS by going into server node, then Server Certificates, then Create a self-signed certificate, and give it a name and either Personal or Web Hosting, and it's created. Then use it in binding of our site (443, https, choosing certificate and domain.local)
However, when we want to go to domain.local in Google Chrome we get that untrusted certificate warning.
We can export certificate in IIS and double click it to install it in Windows. Now the error we see in Chrome is that this certificate is created for LocalComputerName and can't be used for domain.local.
At this point we're stuck at how to specify domains (Subject Alternative Names or SAN) for self-signed certificates, and how to automate this process from command line.
Any help?

Using ssl with localhost with asp.net mvc 5 on VS2015

I'm trying to test my website locally using SSL with IIS Express. It has the following properties set:
SSL Enabled set to 'true'
SSL URL is set https://localhost:44354/
But whenever I open the https address, I get the following error:
In "Microsoft Edge":
In Google Chrome:
I've read article after articles, including some on SO but to no avail. I've tried the following:
I've deleted my IIS Express Development Certificate
I've repaired IIS Express 10 via the Control Panel
I've removed the localhost certificate I had created manually.
I've added <binding protocol="https" bindingInformation="*:44354:localhost" /> to the bindings section the applicationhost.config
I've stopped and restarted IIS Express.
Some suggest to change the port to 443 but my SSL URL is read-only in .NET IDE.
Some articles I've read:
Running IIS Express without Administrative Privileges
How do I fix a missing IIS Express SSL Certificate?
IIS Express — Getting SSL to Work
and many more...
Any help would be greatly appreciated.
Thanks.
I finally figured it out by following this article How to trust the IIS Express Self-Signed Certificate but a few additional steps:
Export IIS Express Development certificate to a local from. This certificate can be found in the Server Certificates section in IIS 10.0.
Open the Certificate console by calling mmc.exe certmgr.msc from File|Run.
Delete all instances of localhost under the Trusted Root Certification Authorities|Certificates.
Import the newly created certificate. You will get prompted with the following:
Once imported, I went back to Asp.Net MVC 5 project, recompile it and ran it. When I ran it, I got prompted with the following:
This is when I knew I was on the right track as this was the first time I had ever seen this prompt! Click Yes, and now this prompt appears:
And click Yes on this prompt as well. Your project will then launch the relevant browser.
Go to the https address defined in your .net project, in my instance, https://localhost:44354/, and you will now see the padlock displayed in the address bar to indicate that it is a secure site:
Most of these answers were already available in different answers provided on SO but the points that were missing or that I missed were that I had to export my IIS Express Development certificate, delete all localhost entries (which I had done) and then re-import this certificate. Once done, .NET detects the change and you get prompted accordingly.
Anyway, I hope this will help others.
Self signed certificates need to be trusted or browsers won't accept them. You can easily use Jexus Manager to configure that,
https://www.jexusmanager.com/en/latest/tutorials/self-signed.html#to-trust-self-signed-certificate
While if you prefer manually, you can import the certificates to the Trusted Root Certificate Authority store in Windows.
Learn more about SSL, certificates, stores and so on (Google each of them and learn them thoroughly), so that next time you really understand what is the culprit before trying so many irrelevant things.
Jexus Manager also has an SSLDiag feature to identify potential issues,
https://www.jexusmanager.com/en/latest/tutorials/ssl-diagnostics.html
But you need to know enough so as to interpret its output correctly.

Odd SSL certificate issue

So, I have a wildcard SSL cert from Go Daddy, and it has been installed on a few servers. However, on one particular server I cannot seem to get this thing done. Here's the process that has worked on all servers but this one:
1. Create CSR
2. Having gotten the certificate from the provider, I open the MMC certificates snap-in and import the intermediate cert to the intermediate authority store (or personal store, both have been tried). This is successful, in that I can view the certificate from the MMC
3. Go to the IIS server and under Server Certificates, I complete the CSR, point to the provided certificate and it imports into the web server successfully.
4. I go to an individual web site to assign the certificate to the web site under binding. When I select https and the IP address, the drop-down menu activates, but the certificate I just installed is not available for choosing.
5. I go back to the server Certificates, and the cert I just viewed is no longer there.
Go Daddy says to rekey, however, this makes no sense, since immediately prior to this, I installed that same wildcard cert to a different server, and it works fine. Obviously, this is something with IIS or Windows on this particular server.
Does anyone have any idea how to fix this without rekeying? Server platform is Windows 2008R2, IIS 7.5
If you have followed steps described in https://www.godaddy.com/help/iis-7-install-a-certificate-4801 then from your side it's done. And for more references, you can also check out this https://stackoverflow.com/a/43247419/7738413
Otherwise, rekeying is the last option.

UCMA 5 NegotiateSecurityAssociation error when machine is not part of the domain

I'm making my first steps in the UCMA world. The samples Microsoft delivers as part of the SDK seem simple enough, but I've hit a snag. If I run any of them from my dev box, I get an AuthenticationException when establishing the UserEndpoint.
The message of the exception is "Unable to perform authentication of credentials". Drilling down to the inner exception, I see this
NegotiateSecurityAssociation failed, error: -2146893039
My Skype 4 Biz pool is in a different domain than my dev box (in fact the dev box is not domain joined), the Skype4B domain CA is trusted though so the error comes somewhere later than in the establishment of a TLS session (initially I got a TLS error since the CA wasn't trusted).
Reading through the SDK documentation, in the chapter about activating trusted applications it is stated that unless you intent to run the Skype4B commandlets or use UCMA auto-provisioning, the machine running the app does not need to be a domain member. So now I'm thoroughly confused.. the same code works in the domain, but doesn't work on my dev box. It can't be a firewall issue because I run some of the clients in my skype4b domain in the same subnet as my dev box.
So what could I be missing?
I'm guessing since you are talking about UserEndpoint's that you are just starting a simple user endpoint UCMA application and you are supplying the username/password to the UserEndpoint?
If that's the case then it's most likely the certificate presented by the Lync server is not trusted your non-domain joined machine. You will need to manually add the root certificate that the Lync Server is using into the trusted cert store on your non-domain joined machine. This is normally the root certificate used by the domain in general, which is why it works on domain joined machines as this certificate is added automatically.
Another test you should do is see if the Lync client runs and connects to the lync server from the non-domain joined machine. My guess is that it will not as it will have the same certificate problem.
The Lync client / UCMA application errors around certificate failures are really bad and hard to understand!