Here is my scenario:
default website on IIS 6.0 is already protected by an SSL cert with common names covering the following:
domainname.com
www.domainname.com
I have a new website on the same IIS server and need to protect it with an SSL cert with the following common name:
subdomainname.domainname.com (same domainname as default)
I do not have the freedom to add a new IP address to the server. Not an infrastructure friendly request for whatever reasons.
We also have our Exchange webmail protected by another cert on another server with:
webmail.domainname.com
I do not believe I can use a wildcard cert because exchange is on a different server, correct?
Whether I can or not use a wildcard server, how can I protect the new subdomain on the main IIS server with a new cert? Do I replace the cert on the default with the new common name representing the subdomain web site and the default web site common names. Can I assign the same cert on the same server with all common names needing protection to multiple websites on IIS 6.0?
Thanks for any help in getting this resolved.
You are correct, you would need multiple signed certificates for your servers. Godaddy offers certs for single-servers only, AFAICT. DigiCert offers multi-domain, multi-server certificates. I've never used them, so I can't vouch for anything they offer, but it shows that what you want IS available in the marketplace.
You can get a single cert and use it on multiple servers so long as the DNS entries map out to the correct servers.
Go Daddy offers several cert types and they don't make it clear how to deal with this issue.
Standard (Turbo) SSL 1 domain ~$30
Standard Multiple Domain (UCC) SSL Up to 5 Domains ~$90
Standard (Turbo) Wildcard SSL ~$200
Get the 5 domain cert with
domainname.com
www.domainname.com
subdomainname.domainname.com
webmail.domainname.com
all listed on the one cert. Complete the request on the server you started the request from then use the tools built into the windows servers to copy the cert from one server to another. Doing so doesn't remove it from the first server and adds it to the second.
I did this not too long ago. My Web server is 2008 and the mail server is 2003. In that combination I had to export as a .pfx file and then import the .pfx. If you do it from 2003 to 2003 you may be able to use the copy from another server option and save manually moving the exported file around.
In my case the cert mentions "Certificate Subject Alt Name" with
Not Critical
DNS Name: www.adomain.com
DNS Name: adomain.com
DNS Name: www.adomain.com
DNS Name: mail.adomain.com
Looks like one of those lines is a duplicate but hey it works. I don't know why the cert uses the terminology of "Not Critical" to head that section.
IIS won't let you put two sites on the same IP/port combo but it will let you put the same SSL on two different sites. The secondary site will have to use something other than 443 if you don't have the option of using a different IP address.
Related
Scenario:
I have built a job board for a client and am running that website on my server while the client’s main website is still hosted in its original location.
client.com (root) is on client’s server
jobs.client.com on my server
“jobs” is set up on client.com as an “A” record pointing to the IP address of my server. A real subdomain has not been created on client.com’s server.
Problem:
I am getting a SSL error because it seems jobs.client.com is not covered by a certificate.
Question:
Is it just a matter of time before client.com’a certificate provider will detect and cover the new subdomain?
Or will I need to add a certificate to jobs.client.com on my server?
Is it just a matter of time before client.com’a certificate provider will detect and cover the new subdomain?
No.
Or will I need to add a certificate to jobs.client.com on my server?
Yes. The certificate covering the hostname specified in the URL needs to be explicitly installed at the server which serves this hostname. It is unclear what kind of certificate your server currently provides, but likely the wrong one.
I have one scenario where I am working on the IIS Website Configurations for URL Routing.
I have added the website and Import the required Certificates on the server.
My scenario is (I have multiple website URLs and two SSL Certs - as below):
qatest1.abc.com
qatest2.abc.com
qatest3.abc.com
Above 3 URLs need to be configured on one SSL Certificate - which is QA Certificate.
Another URL is:
perftest.abc.com
And for this URL there is a separate certificate as PERF (performance) certificate.
This is how the Task is given to me to configure the IIS Settings on MS IIS 10.
Now the Issues which I am facing is:
Not able to configure all the URLs configuration on the same IIS, as per the task given to me I am supposed to configure them all on the same IIS.
Getting a strange message (image attached) and it won't allow me to configure all my above website URLs on the same machine, on the same IIS.
Also trying to read about SNI (But Not sure about how to make use of SNI in this case).
Need help from IIS Experts who can support me on this activity to complete.
you could check the Server Name Identification by using this you can avoid the certificate prompt.
This feature offers an easier solution to hosting multiple sites that have a different or individual SSL on a single IP address.
Each HTTPS binding requires a unique IP/port combination because the Host Header cannot be used to differentiate sites using SSL.This is because the host header is not visible during the SSL handshake.
Server Name Indication (SNI) allows the server to safely host multiple TLS Certificates for multiple sites, all under a single IP address.
#1 - its possible via CLI commands (appcmd & netsh) or scripting (PowerShell) and programming (c#) but not with the IIS Manager GUI afaik.
#2 - (see #1). IIS Manager is stupid and will overwrite existing bindings with the last certificate selected. You end up with bindings attached to the wrong certificate if you click Yes. This is a limitation of IIS Manager GUI not IIS.
#3 - You want SNI turned on. It means you can have multiple certificates associated with the same IP address. Without SNI you would need 1 IP address per certificate
These 2 links will give you an idea how to use appcmd and netsh - this is the quickest/easiest way to create your desired configuration.
Adding a HTTPS binding to a site
Binding a certificate with netsh
If you know PowerShell("POSH") you can use the IISAdministration PowerShell cmdlet New-IISSiteBinding to create bindings and associate with a certificates thumbprint (though netsh is still useful for debugging and fixing issues).
Either approach your really configuring 2 things - IIS' bindings and Windows/SChannel/HTTPS.sys (the operating system component actually responsible for the 'S' in 'HTTPS'). Sometimes they get out of sync and the easiest fix is to delete and re-create the bindings (after clicking yes to "At least one other site is using the same HTTPS binding..." for example).
Few tips:
Once you start using this configuration IIS Manager or Windows Update/software installs will probably break your bindings at some point. Write a script that can remove and re-create all your bindings for port 443(only!) so you can easily fix future issues.
If you use netsh - its very fussy about the syntax. Order and spacing of parameters are important when using command netsh http add sslcert.
While your testing netsh http show sslcert and netsh http delete sslcert are very useful to try different configurations (this wont delete the cert, just the binding)
Cert needs to be in the Machine certificate store and make a note of the path. When using POSH or netsh always specify both certificate thumbprint and the store\path where the cert was installed.
If you need a default HTTPS binding on the IIS Site (eg load balancer healthchecks etc) add it before any named HTTPS bindings.
Final aside - if your domains are all 1 level under abc.com getting a wildcard certificate would save you a lot of bother. a single *.abc.com certificate would cover all your domains and you can avoid this limitation entirely.
Good luck!
I'm migrating servers, moving my sites from VPS A to VPS B. I use Let's Encrypt for all of my 10 website's SSL certificates. Before I start this migration process I need to know issues that I might be running into.
I have used win-acme to create certificates for ALL of my 10 websites on VPS A.
I want to test migrating 1 site, let's call this site X, to VPS B first.
Then after I copied all data for site X from VPS A to VPS B, I want to generate the SSL certificate and change my DNS settings so site X no longer points to VPS A, but to VPS B.
My question is: when I run win-acme on VPS B and generate a new SSL certificate for site X, can I have 2 SSL certificates for the same domain name that were generated for 2 different servers? Or will Let's Encrypt invalidate one of them?
Hopefully my question is clear, any context/further info is highly appreciated!
Already checked here and here.
Let's encrypt uses the ACME protocol the default verification method is based on the server being able to respond to a specific http request (which is only possible if the IP matches).
It is however possible to use DNS certification, win acme has a plugin to do dns verification. I have no experience with win acme, but with certbot DNS verification is automated for some dns providers and requires manual steps for other dns providers.
With DNS verification it's possible that you have a certificate for a domain on multiple servers. With the regular verification it isn't possible.
You could copy the cert to the other server.
Test it by adding you local dns with the new server ip for the domain you have to test.
The copy steps depend on the system you are using.
https://community.letsencrypt.org/t/move-to-another-server/77985
I've got an ssl certificate for what I think is my domain and I want to apply it to two separate applications in that domain that run under ASP classic in IIS on Windows 2000.
I have the following stupid questions:
Are certificates issued for URLs or domains? Or subdomains?
Can I use the same cert for multiple websites (applications) within that domain, or do I need a separate one?
Can I inspect the cert file to determine for what or to whom it's issued?
Thanks!
1) Web certs are issued to a domain. Specifically the CN attribute of the certificate must match the domain used to access your site.
2) Certs are usually install per host (or virtual host). If you had cert for the domain wwwapps.domain.tld you could have one app at /calendar, and one app at /contacts.
3) Yes, depending on the format and where it is, this can be easy or hard. If you have a crt file and you are running under windows, just click on it. You should see the details.
If you want to inspect a certificate that is installed on a site, you usually have to click on the padalock icon.
On windows you can also open up the MMC, add the certificate snapin and see any/all installed certificates on the local machine, or your profile.
They are issued for domains. Subdomains require their own certs. You can buy a special wildcard cert for your domain that lets you create certs for your subdomains, but they are more expensive.
If you buy a cert for mydomain.com, you can use it for anything that starts with https://mydomain.com/
Yes. You can do this for any certs. check out the lock icon in your browser's address bar.
It's usually issued to a single web server host (basically a computer cname or a record) like foo.bar.com where foo is one name for the host which the certificate request was generated for and bar.com is its domain.
Thus it will work for any application or virtual directory that responds to https://foo.bar.com - like https://foo.bar.com/planner/ - but nothing more.
For https://*.bar.com you can get a wildcard certificate that lets you handle any number of hosts without any hassel - at a greater cost.
There are also multiple-SAN (UCC) certificates that can contain a specific number of host names in a single certificate like webmail.bar.com and autodiscover.bar.com for an Exchange 2007 server serving both web access and Outlook Anywhere from the same physical machine and NIC.
If it's in .cer format simply opening it in Windows will show the details, if it's a pfx or in some other transport format you'd need to import it.
You basically install the certificate on a Web Site node in IIS and anything you can fit beneath that (or modify using a modern firewall in front of it to still respond to the issued common name foo.bar.com) will work.
Thanks! I enabled port 443 for the site at the domain on the cert, loaded the cert via directory security in IIS for each subfolder, and enabled 128-bit encryption. Worked like a champ!
I'm setting up a webserver for a system that needs to be used only through HTTPS, on an internal network (no access from outside world)
Right now I got it setup with a self-signed certificate, and it works fine, except for a nasty warning that all browsers fire up, as the CA authority used to sign it is naturally not trusted.
Access is provided by a local DNS domain name resolved on local DNS server (example: https://myapp.local/), that maps that address to 192.168.x.y
Is there some provider that can issue me a proper certificate for use on an internal domain name (myapp.local)? Or is my only option to use a FQDN on a real domain, and later map it to a local IP address?
Note: I would like an option where it's not needed to mark the server public key as trusted on each browser, as I have not control over workstations.
You have two practical options:
Stand up your own CA. You can do it with OpenSSL and there's a lot of Google info out there.
Keep using your self-signed cert, but add the public key to your trusted certs in the browser. If you're in an Active Directory domain, this can be done automatically with group policy.
I did the following, which worked nicely for me:
I got a wildcard SSL cert for *.mydomain.com (Namecheap, for example, provide this cheaply)
I created a CNAME DNS record pointing "mybox.mydomain.com" at "mybox.local".
I hope that helps - unfortunately you'll have the expense of a wildcard cert for your domain name, but you may already have that.
You'd have to ask the typical cert people for that. For ease of use I'd get with the FQDN though, you might use a subdomain to your already registered one: https://mybox.example.com
Also you might want to look at wildcard certificates, providing a blanket cert for (e.g.) https://*.example.com/ - even usable for virtual hosting, should you need more than just this one cert.
Certifying sub- or sub-sub domains of FQDN should be standard business - maybe not for the point&click big guys that proud themselves to provide the certificates in just 2 minutes.
In short: To make the cert trusted by a workstation you'd have to either
change settings on the workstations (which you don't want) or
use an already trusted party to sign your key (which you're looking for a way around).
That's all your choices. Choose your poison.
I would have added this as a comment but it was a bit long..
This is not really an answer to your questions, but in practice I've found that it's not recommended to use a .local domain - even if it's on your "local" testing environment, with your own DNS Server.
I know that Active Directory uses the .local name by default when your install DNS, but even people at Microsoft say to avoid it.
If you have control over the DNS Server you can use a .com, .net, or .org domain - even if it's internal and private only. This way, you could actually buy the domain name that you are using internally and then buy a certificate for that domain name and apply it to your local domain.
I had a similar requirement, have our companys browsers trust our internal websites.
I didnt want our public DNS to issue public DNS for our internal sites, so the only way to make this work that I found was to use an internal CA.
Heres the writeup for this,
https://medium.com/#mike.reider/getting-firefox-chrome-to-trust-your-internal-websites-internal-certificate-authority-a53ba2d4c2af
i think the answer is NO.
out-of-the-box, browsers won't trust certificates unless it's ultimately been verified by someone pre-programmed into the browser, e.g. verisign, register.com.
you can only get a verified certificate for a globally unique domain.
so i'd suggest instead of myapp.local you use myapp.local.yourcompany.com, for which you should be able to get a certificate, provided you own yourcompany.com. it'll cost you thought, several hundred per year.
also be warned wildcard certificates might only go down to one level -- so you could use it for a.yourcompany.com and local.yourcompany.com but maybe not b.a.yourcompany.com or myapp.local.yourcompany.com, unless you pay more.
(does anyone know, does it depend on the type of wildcard certificate? are sub-sub-domains trusted by the major browsers?)
Development purpose only
This docker image solves the problem (thanks to local-ip.co): https://github.com/medic/nginx-local-ip.
It launches a reverse proxy in the port 443 with a public cert that works with any *.my.local-ip.co domain. Eg. your local IP is 192.168.10.10 → 192-168-10-10.my.local-ip.co already points to it (it's a public domain)! Assuming the app is running in your computer at the port 8080, you only need to execute this to proxy pass your app and expose it at the URL https://192-168-10-10.my.local-ip.co:
$ APP_URL=http://192.168.10.10:8080 docker-compose up
The domain is resolved with any public DNS you have configured in the devices where you want to access the app, but your traffic keeps local between your app and the client (through the proxy), so you can even use it to connect with devices within the same LAN network, without any of the traffic going out to internet, all the traffic is local.
The reason that is mostly useful for development is that anybody can launch an application with this same certificate, so is not really secure, but helpful when you need to expose your app with HTTPS while developing or testing (e.g. HTML5 apps in Android that are loaded with Webview).