I hosted an ASP.NET Web API project in my Windows 7(IIS7) developer machine on HTTPS(443) and SSL Required ticked with Require Option true.
For testing I give its host header value : www.certtest.com, and the same I add in host file of local machine.
Also we have a W2k3 machine where we've configured the CA and obtain test certificates from it.
We import same certificate in IIS7.0 for client authentication.
When we try access site, the first time it asks me for certificate and after that certificate get installed with root certificate in my local store but i see 403.7 Forbidden error immediately.
Also, I tried with self signed certificate.
Same problem with that too.
Do we require a valid trial certificate for client authentication by Thwate type CA to accomplish this?
Yes this is a case where we don't have valid certificates, for testing you can set SSL Settings as Accept and see if things work fine for you.
However you will need valid certificates for the same.
Related
I have an asp.net web app deployed on IIS7. I call the webapp AOps and When I try accessing the web app over https it just crashes saying "Security sertificate required to access this resource is invalid" (first image).
When I try over http the download works fine.
When I access the default IIS app over both http and https it works fine - except that it complains that the address is mismatched.
I have added a .pfx certificate in the certificate store with the same host name as my host, so the certificate should be fine. Any idea where to start reviewing my configuration?
I am used to apache and tomcat but IIS is a different animal. I looked in the IIS log but it's pretty much a black box. Any help would be greatly appreciated.
The certificate error is generated by your browser not the server. There are 3 things the browser cares about.
The name on the certificate needs to match the url you are using. So in your case, the browser wants a certificate issued to "localhost"
The certificate has to be issued by a trusted certificate authority (not self-signed)
The certificate cannot be expired
To solve 1, use a host entry in /etc/hosts. To solve 2, you need to add the certificate to trusted CA store on your local machine. And 3 is pretty obvious.
I have deployed a WCF service on IIS and enabled SSL for it. I created a self signed certificate on the server and exported into a pfx file. I also brought the pfx to my machine and installed it under Trusted Root Certification Authorities.
When I hit the service URL, I get following warning which I need to avoid:
You attempted to reach 172.150.170.226, but instead you actually
reached a server identifying itself as something.something.local.
Please suggest. Thank You.
The host name on the certificate has to match the host name in the URL you are using. So you need to be hitting something.something.local. If that doesn't work, then maybe it needs to be set up in your hosts file so that the IP resolution works.
The problem was I was unable to name the self signed certificate according to my preference.I was accessing the service through the ip address of the server , so i needed to set the common name of the certificate as that ip.
I was able to do this using SelfSSL.exe which comes with IIS 6.0 Resource kit.Using this tool from command line I was able to name the certificate as i like.
I have asp.net site on my local machine.
IIS configuration:
binding: https binding with self-signed certificate,
ssl settings: Require SSL and Require client certificates
I have installed next certificates on my machine:
CA certificate (call it 'CA Center') in Trusted Root Certification Authorities store.
Client certificate issued by 'CA Center' in Personal store
I go to site and accept server certificate. But next i get error:
HTTP Error 403.7 - Forbidden. The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
That means browser (IE) doesn't send applicable client certificates to server.
What's wrong? Should I configure something else?
I had exactly this problem, and it took me an age to figure out the cause. Turned out it was because my computer was part of a domain, and there was some sort of group policy for that domain was restricting the trusted root certificates that IIS would be willing to accept. I don't know exactly what the setting was or how to alter it, but I found I could work around it by choosing to install my certificate into the enterprise physical store using the certutil command:
certutil -addstore -v -enterprise root CertificateAuthority.cer
It sounds like the browser never prompted you to select a client certificate to send which means something is incorrect with the SSL Handshake. Try testing this with OpenSSL.
Additionally, a very common problem is having too many certificates in the Trusted Root CA folder. When the server sends the list of CAs, there is a limit to how large the list can be so if it exceeds the limit, it will truncate the remaining CA certificates. Make sure the Trusted Root CA folder doesn't have too many certificates. One way to check this is temporarily modifying the SCHANNEL in the registry editor to not send the CA List, and then re-try.
Start > Run > 'regedit' > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL >
right-click > New > DWORD > 'SendTrustedIssuerList' > Value:0
Re-install the certificates and check their effective dates. From Microsoft Support:
Download the root server certificate in a browser on the server
computer. Run the Iisca.exe command line utility that is located in
the Inetsrv directory.
Check the effective date on the client certificate and make sure that
the date and time has arrived.
Check the expiration date and make sure that the certificate has not
expired. Contact your certificate authority to see if your
certificate has expired.
I have a website on our Internal network that is also accessible to the public. I have purchased and installed an SSL certificate for that public site. The site is available using both https://site.domain.com (Public) and https://site.domain.local (Internal).
The problem I am having is creating and installing a self-signed certificate for the internal "site.domain.local" so that people on our internal network do not get the security warning. I have a keystore in the root folder and also created a self-signed certificate in that keystore with no luck. The public key is working just fine. I am running Debian linux with Tomcat 7 installed and I am also using Active Directory on the network with Microsoft DNS. Any and all help would be greatly appreciated. If you need more details, please ask.
Not sure I fully understand your set-up, but you could front your Tomcat with Apache, install the cert on the Apache instance and then do a Reverse-Proxy (plain http) to your Tomcat instance. People would access the Apache instance which would handle the SSL connection.
One way would be to add the CA certificate in every client certificate trusted store (which is not convenient) : the client click on the certificate warning message and install/trust the self signed x509 CA certificate. If this doesn't work, there is a problem with the certificate (though most openssl generated stuff .CER/.CRT/.P12/.PFX will install with no problem under recent windows).
If one client accepts the self-signed certificate with manual setup, you can try to install these certificates with Active Directory ; basically you add trusted CA cert within your AD, and client automagically synchronize (nb: mostly on login) : See there for a hint about setting thing up with AD : http://support.microsoft.com/kb/295663/en-us (You may try this or dig in that direction : with AD, you never know).
Another possibility would be to set up your internal DNS to point site.domain.com to the local web site address (the easy way). You can test this setup with you /etc/hosts file on linux/unix flavours (or system32/drivers/etc/hosts on windows flavours)
If your certificate is for site.domain.com and users are going to site.domain.local and getting that cert, then clearly there is a name mismatch and the browser will always warn you.
You either need to :
get the cert regenerated with BOTH names
get a cert for just the internal site
mangle DNS so that when your internal users go to site.domain.com
they get the IP address of site.domain.local.
I need to install a certificate for encryption (replication) between an external vendor and my company.
I cannot get a third party certificate for the FQDN of my server because the net part of that does not match a domain that we own (ie my FQDN is sqlservername.company.root.net but we don't own a domain called company.root.net.). We do own mycompany.com, so I got sqlserver.mycompany.com on the cert and have a DNS entry to alias sqlserver.mycompany.com to sqlservername.company.root.net.
I cannot use a self generated cert since the vendor needs to trust the cert authority.
I have a cert that I have purchased and installed, but SQL Server won't see it since the FQDN doesn't match.
I tried installing it by putting the thumbprint of the cert into the registry directly, but then SQL server won't start with the following errors:
The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030e. Check certificates to make sure they are valid.
Unable to load user-specified certificate [Cert Hash(sha1) "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]. The server will not accept a connection. You should verify that the certificate is correctly installed. See "Configuring Certificate for Use by SSL" in Books Online.
(where the x's above match the thumbprint of the cert without spaces)
TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. Cannot find object or property.
What do I need to do differently to get this working?
You need to use MMC to install your certificate in the certificate store and then use the SQL Server Configuration Manager to link the certificate to your SQL Server service. See https://support.microsoft.com/en-us/help/316898/how-to-enable-ssl-encryption-for-an-instance-of-sql-server-by-using-mi
Then, make sure that the service-account running you SQL Server service has full permission on the certificate. In MMC, right-click on the certificate, select Manage private key, and then grant full access to the service-account running you SQL Server.
You should restart your SQL Server for the changes to take effect.
Before anything else, you must install the certificate in the Windows certificate truststore.
Did you do that?
The error
You should verify that the certificate
is correctly installed
seems to indicate you did not do this.
I was expecting that the hostname verification would be configurable but from here SSL in MS-SQL2008 r2 it seems as an absolute requirement.
To be honest I am not sure if the trick you did with the DNS entry will work.
It seems that some tweeking works for cluster installations ssl for cluster installations
In your case, may be you should have bought the certificate using the IP as subject name and use DNS to resolve to the FQDN you say.
But of course this implies use of a static IP and most likely it would not be feasible as well anyway.....