I'm migrating a web app from an IIS 6 server to an IIS 7 server and I'm having some troubles with getting the client's certificate.
The piece of code that I'm using looks like this:
HttpClientCertificate cert = Request.ClientCertificate;
if (cert.IsPresent)
{
...
}
On the IIS 6 server, the cert.IsPresent is always true. However, on the IIS 7 box, it is always false. Both tests were done with IE 8 from the same computer. The only change was the Server URL, so the client should be setup correctly.
I'm not getting any SSL connection errors (I'm accessing the page via https) and I've set the SSL Settings -> Client certificates: to Accept (same as the IIS 6 configuration).
I've gone through and configured the IIS 7 server as closely as I could to the IIS 6 server, but I'm still not getting the cert.
Are there other areas that I need to look at for configuration?
Also, if I set the Client certificates: to Required, I get a 403.7 error on the IIS 7 box. I don't know if that is a symptom, but just in case the information is useful...
Basically it boils down to the fact that the client can't provide the client certificate.
That's why you get the 403.7 error when you require it.
I believe you need this:
http://blogs.msdn.com/b/puneetgupta/archive/2009/08/03/where-is-the-client-certificates-ui-in-iis-7-0.aspx
Please let me know if this helps.
I came across this question while looking for more information about how to get certificates in IIS 7 vs. IIS 6. I see that #whosrdaddy's solution worked for the asker. There is something else that I had to hunt down.
One of the differences between IIS 6 and IIS 7 is that IIS 6 has the "Directory Security" tab in each web site's configuration. In order to make the web server request certificates in IIS 7, you must click on the "SSL Settings" feature for the Web Site or Virtual Directory you are configuration to see the "Client certificates:" setting: Ignore, Accept, or Require.
Make sure that this is not set to "Ignore", or else you will never get your certificates to work!
The IsPresent == false can be caused by several different things, both related to the server and the client. We hit everyone of these on the way to finally fixing these and I will detail each....
Server Issue #1 - The client cert passed in has 1 or more certification paths that do NOT exist on the server. Open the cert go to certification path (tab) and make sure each of the root authorities are in the SERVERS trusted root certificate authorities. Note, you DO NOT need to install the cert on the server just the root authorities public keys under Certificates (Local Computer) \ Trusted Root Certification Authorities.
Server Issues #2 (previously mentioned solution) - In IIS, for the site, make sure the SSL Settings are set to Accept OR Require (never ignore). The benefit of using Require is that the IIS logs will show you are 403 7 error where as Accept will just get your the IsPresent == false but with a 200 http code.
Client Issue #1 - Same as server issue #1, got to trust those authorities!
Client Issue #2 - You have the trusted root authorites but NOT the private key for the cert itself. Make sure you install the pfx (private key) into the cert store not the public key (.cer). You can also see if you have the private key by double clicking the cert in the cert store and on the general tab you should see a message saying as much.
Client Issue #3 - You put the cert in the wrong place. Probably best to place your cert in Certificates (Local Computer) \ Personal \ Certificates, rather than (current user). This will make the cert available to process accounts that are running your code and actually need access to it.
Client Issue #4 - Right mouse click the cert (in the store not a .cer file) --> All Tasks --> Manage Private Keys... and make sure the process account running your code has "Read" permission. A quick test of this (but not recommended for production use) is to add "Everyone" as read to see if this is your issue.
Related
I am transfering a website and when am navigating to a page my url is changing from HTTP to HTTPS. Here am getting the Privacy Error message in my browser.
How can I avoid this in moovweb transformation?
Let’s take the example of http://mlocal.erin.ne.jp/
When we are choosing Japanese version its pointing to https://mlocal.erin.ne.jp/jp but in my browser when its moving to secure site am getting Private error.
How can we set-up the config to avoid such error?
I tried with ssl_whitelist but no luck :(
{
"host_map": [
"$.erin.ne.jp => www.erin.ne.jp"
],
"ssl_whitelist": [
"erin.ne.jp",
"erin.ne.jp/jp",
"https://erin.ne.jp/jp"
]
}
Thanks in advance !!!
The ssl_whitelist configuration option is only necessary if the website you are trying to transform has invalid certificates. Typically, this might be a staging website where it is known that the certificates are invalid. So this option is unrelated to the problem you are seeing.
During local development, the Moovweb SDK will load a self-signed SSL certificate for the local domain. This is provided as a convenience to simulate SSL traffic.
When you hit https://mlocal.erin.ne.jp, that is your local server with invalid SSL certificates. Because there is no chain back to a root certificate authority, your browser will not trust the certificate.
If you acknowledge the error, you will be able to proceed. I am only recommending this because this is a local development situation only. During normal web browsing, take care when you see similar messages.
This is completely separate from production-ready projects that will be hosted on the Moovweb cloud. In production, you will have to acquire valid SSL certificates that matches the production domain name you select (typically m.erin.ne.jp, t.erin.ne.jp, or www.erin.ne.jp for a single-domain project). Once this is set up properly, you will not see any SSL certificate errors on your production domain.
I have been trying to configure a website I deployed on my local server with a self signed certificate for development purposes. The address I want my website to work for is example.company.local.
After I genrated a certicate using SelfSSL, I copied it to the Local Machine store in both Personal and Trusted Certifciate root . But I get the error "Server's certificate does not match the url" when I try to reach the url. Though I can ignore it, I understand that the cert auth is failing and I want to fix this. I am listing the steps I followed
Generated self signed cert using selfssl /N:CN=example.company.local /V:9999. This added the certiciate to my Personal store on Local Machine
From the mmc (type mmc in Run), I add the cert generated above to the to Trusted Root Certificate folder from the Personal folder
Restart IIS
Please suggest where I am going wrong. The url I give is https://example.company.local, but it refers to a localhost certificate.
Please try this guide. From the comments on the page it seems to be working but I did not test it.
If by any change there is still a problem I would suggest to use xca. It is built on top of openssl, has very nice GUI and has templates for CA, SSL server and SSL client. Documentation can be found here.
Migrated a fully-functioning Drupal 7 site and corresponding database to a new server. I am unable to login to the admin side. The error message is: “Access Denied. You are not authorized to access this page.” The username and password has been verified.
I looked at /admin/reports/dblog, the error log shows 2 entries per login. One entry shows the session is opened for the correct username, and the other entry shows access denied and the user is ‘anonymous.’ It is my assumption that Drupal is not able to validate the user so it is assigning the user as anonymous.
I read many forum topics on similar issues. I commented out the ‘$cookie_domain’ in ‘settings.php’, but still nothing. I looked back at the functioning site and saw that 2 cookies are generated: ‘has_js’ and a session ID cookie. In the new site, only the ‘has_js’ cookie is generated (using both Firefox and Chrome browsers). I have verified that the session id is being saved to the session table in the database.
I have looked into modifying ‘php.ini’ (etc/php5/apache2/php.ini) but have not found a solution that saves the session id cookie.
Drupal 7
Linux Server
Ubuntu 12.04
Apache 2.2.22
MySql 14.14
PHP 5.3.10
Uncomment line 340 on settings.php to reflect your domain name
e.g. for localhost
$cookie_domain = 'localhost';
Please note this works for drupal 7 and my php version is 5.6.
Regards,
When migrating drupal installations from server to another there is several problems that could appear.
1) check your file permissions, because sometimes we migrate files from server to another and having different owner:group and this gives serious problems.
2) You need to delete all cache before migrating to avoid having access problems and using wrong urls from cache and so on, in your case you already migrated Drupal, so you need to go to the DB and delete content of all cache_* databases. this could help you.
3) if not you need to look at what php version you have been using and mysql and apache maybe some deprecated functions or so.
I had the same problem, except that I could see the session cookie in Chrome (Settings -> Show Advanced Settings -> Content Settings -> All Site Cookies and Data). The cookie's "Send for" property was set to "Secure Connections Only" and my site was running up on HTTP / port 80. Thus the browser would not send the cookie back to the web.
The problem turned out to be this line in php.ini: session.cookie_secure = 1
When this option is set, PHP will specify that the cookie may only be sent over a secure (HTTPS) connection. This makes it harder to mount a man-in-the-middle attack because the cookie is no longer sent via clear text.
There are two ways to resolve the issue: 1) Switch the site to HTTPS. 2) In php.ini, set session.cookie_secure = 0
I had the same problem. Number 3 from the first answer saved me - I'd recently changed my MAMP PHP version to 5.6 and this seemed to be causing the issue. Reverting back to 5.5 means I can now login.
My IIS site is giving browsers problems. They pop up a security warning that the security certificate does not match the name of the site. I'm using a self-signed certificate for testing. I view the certificate. It has the name.
DnsName.mydomain.com
but the browser is using
MachineName.mydomain.com
There is a CNAME entry pointing DnsName.mydomain.com to MachineName.mydomain.com.
Even so, they are obviously different. Can you tell me how I can get a new self-signed certificate with the name MachineName.mydomain.com, and how to install it on my test web server such that browsers can use either name without getting this security warning?
I can have the browser install any certificate a self-signed cert from my web server, that's not the problem. The problem is the warning. Here's a screen shot of what I mean.
You can only have one cert per site.
There are a couple of heavy-handed ways of getting around this:
Completely duplicate your site and have a cert on each
Use SSL-Acceleration and have two different external IPs on a load balancer that both point to the same internal.
There's also one easy way since you're already self-signing: Just wildcard it (*.mydomain.com). Generating this on a Windows box is explained here and Generating this on a Linux box is explained here.
If you really don't want to do that, I'd just have a forced redirect from one URL to the other instead of a CNAME alias.
We're experiencing some really strange problems with Integrated Windows Authentication with IIS and I'm not sure if I can see a pattern or not.
We have a DNS-Cname record called Fred. We have an IIS website with Fred set as the host header. When I connect to this site I get prompted with a credential challenge. I would expect my credentials to have been passed through. If I enter my credentials I am granted access.
I then create a local host entry called Betty and point the host file to the same IP address as Fred and change the host header to Betty. There is no associated CName record anywhere. When I access Betty I am authenticated automatically and everything is fine.
If I attempt to bypass the CName record and create an entry in the local host file called Fred and change back the host header to Fred. I still receive an authentication challenge.
As I see it have two questions. How is this CName record affecting the resolution here or is it a red herring. Secondly what is happening with this challenge? We have similar symptoms elsewhere and our concern is that our authentication token is getting blatted somewhere. Could someone walkthrough the order in with Authentication occurs i.e. what packets are sent to what machines. Is there a way I can trace this? (I'm thinking WireShark or something similar). How can I prove my authentication token is getting passed and is valid?
The reason for the authentication box is simple: Internet Explorer sends your credentials only if it thinks the host is in the "Local Intranet" zone (default configuration assumed). If a host outside what IE deems to be "local" asks for NTLM credentials, an authentication box will appear, and you have to authenticate manually.
If you want your credentials to be sent automatically, make sure IE thinks it in "Local Intranet". Check the zone info far right on the status bar to see the currently active zone.
IE takes into account multiple things in order to decide whether a host is to be considered as "Local Intranet":
is it an IP address in the local sub-net -> YES
is it a simple host name (i.e. "no dots") -> YES
in the IE options: is it in the "Sites..." list for "Local Intranet" -> YES
in the IE options: is it in the proxy exclusion list -> YES
is it an UNC path -> YES
otherwise: NO
Sometimes, an old password exists in the personal passwords list for that host name (accessible through Control Panel -> User Accounts). If it is wrong, similar issues can occur.
My suspicion is that your host "fred" does not fulfill conditions #2 through #4, but your test case "Betty" somehow does.
What way the name was resolved (CName record, A record, hosts file, other) makes no difference, because the method of name resolution is opaque to the calling application. IE just asks for name "XYZ" and gets an IP address back.
Recent configuration changes can require you to clear the local DNS cache, though. An occasional ipconfig /flushdns would help here, alternatively you can stop the DNS Client service for a while.
The described internal logic is applied to the host name and security settings change based on the outcome.
CName would be a red herring. Has no effect on Windows Auth or not.
The easiest way to trace it is with fiddler. You should see your request followed by a 401 response (it contains the authentication the server supports), then your request again is sent with the authentication details (or you are prompted and then it's sent)