I have a website built and running on IIS / Win 2012R2, its only accessible within my local network and will never reach the outside world.
Currently, I'm using a self-signed SSL certificate that I have installed on all my windows machines, no problem!
I now need to get the website to work on Android 7.7 tablets, without the chrome browser complaining about the use of a self-signed certificate. I'm not able to install my Self-Signed certificate on these devices so I need to use an online CA.
The question is, how can I link an online CA to our internal website? The key issue being I don't have a domain, the path to access the website is https://servername/website
Is this even possible at all?
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.
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!
I am wondering if this is at all possible.
I know how to create a self certified SSL on my DEV box
Server > Server Certificate > Create Self Signed Certificate > friendly name
But when i do one one these its for XYZ.mycompainies.com as in its issues to the server.
but i don't want it to be issues to that server name...
on my box i have lets say hello.OddDev.co.uk which is working fine but now i need to test some https stuff on the website, how can i get a self certified SSL for that URL when i have no option to generate one in the GUI
Probably this will help you:
http://corvartech.blogspot.ru/2013/02/generate-self-signed-certificate-on.html
In short IIS certificate creation wizard is easy but doesn't allow for custom CN, and if you need this you may use SelfSSL.exe
And if you haven't yet tired of warnings about this in MS documentation keep in mind that self-signed certificates are for development/test purposes only.
We're having an issue with securing an intranet / internet website with SSL where
we can't know the qualified domain name in advance.
Basically, I'm trying to make a program that will be installed on a webserver
outside my direct control, to be accessable over intra- or internet. In either case
I want it to be secure via SSL (https). To do this, I would like to include and
install a SSL certificate on the target machine. My installer is fully prepackaged
and should not require any particular during- or postinstall intervention from my
end. Problem is, I can't know ahead of time the target machine's name or domain
name, so as far as I can tell the SSL connection will be returning warnings (or
worse?) when accessed, since the certificate I include will (must) have a different
name on it.
I really want to avoid those warnings, but I still want to keep it secure. Is there
any way to install a SSL connection without certificate warnings without the domain
name known ahead of time?
Thanks for any help you folks can give.
What you want to do is not possible. Here's why.
A certificate will include a set of names (Common Name, possibly along with Subject Alternative Names, possibly including wildcard names).
The client's web browser will do the following:
The user wanted to visit "https://myapp.mydomain.com/blog/posts/1".
The request is via SSL and the domain name in the request is "myapp.mydomain.com".
Get the certificate from the Web server.
Ensure that at least one of the names in the certificate is exactly equal to, or wildcard-matches, the domain name in the request.
Display the page.
Therefore, you need a certificate with the exact domain name (or a wildcard matching the exact domain name) by which the application will be used. And the certificate needs to be available at the same time as, or later than, the time when the exact domain name of the website becomes known, and cannot be made available any earlier.
You seem to be under the misapprehension that somehow a certificate can "create" or "install" an SSL connection. That is false. The Web server - Apache, IIS, Nginx, LigHTTPD, or whichever one you happen to use - is the program that knows how to every aspect of SSL connectivity. The certificate is just a file that the Web server sends to the client, without even opening or using in any way.
Additionally, the author of a webapp to be distributed is not responsible for creating or distributing certificates, and should not be under the misapprehension that he is responsible. Only the website maintainer should be responsible for obtaining a certificate for his website. As another person remarked, in your installation process or perhaps in a post-installation process, you may ask the person installing the webapp for a certificate. But that is the best you can do.
The best you can do is to buy a wildcard SSL certificate - but wait, it's not what you think. You still need to know the second-level domain (the TLD being ".com") ahead of time. You can effectively ask for a cert that covers *.foo.com - then any site, a.foo.com, b.foo.com will be covered. Of course, these certs are more expensive that FQDN certs because you are doing the buggers out of some extra coin.
-Oisin
Each of those sites should have their own SSL certificate. Why not prompt the user to provide the cert file during installation?
In most (if not all) cases, the SSL certificate is associated with the webserver (apache, IIS, etc.) and is not part of your application. It's up to the admin of the web server to install the certificate and not you as the author of the program.
If your installation program does have the ability to modify the web server configuration, and you are willing to have it use a self-signed certificate, you can script the creation of the certificate to allow the domain name to be input. However, I sense this is not really available to you. Also, a self-signed certificate will generally cause certificate warnings.
If I understand you correctly there might be a solution to your problem now. This solution won't help you, however, if you have no control over specifying what SSL certificates are served from the web server where your program is installed (as mentioned by someone else). If your program itself contains a web server you won't have this issue.
If you start with a trusted https website, you can make cross-domain TLS (SSL) XmlHttpRequests to the web servers that are running your application. This is made possible using the opensource Forge project. The project uses a TLS implementation written in JavaScript and a small Flash swf to handle the cross-domain requests. Your program will need to serve an XML Flash policy file that grants the trusted website access to the web server running the application.
Your program will also need to generate a self-signed SSL certificate and upload it to the trusted website. From there, each program's certificate can be included as trusted via the JavaScript TLS implementation. Alternatively, you can have your program upload its certificate to be signed by a CA you create, using a common or subject alternative name that is appropriate for your use (it doesn't have to be the domain name). Then you can use JavaScript to trust the CA certificate and look for the correct name on each certificate.
For more details check out the Forge project at github:
http://github.com/digitalbazaar/forge/blob/master/README
The links to the blog posts at the end provide more in-depth information about how it works.