What type Certificate to use to have no user interaction? (ACS 5.1)

[dal]

Hi.

I have set up a Windows 2003 Certificate Server to use in AutoEnrollment for machine and user 802.1x authentication, but has run into a few problems.

The steps are something like this:

I configured the CA Server.

I requested a certificate from the CA server inside the ACS 5.1, and installed it.

I downloaded the root certificate from the CA server, and installed it on the client (WinXP SP3).

So far so good, and the web authentication part (when I log in to the ACS itself) works fine.

But when I try to authenticate a client, both on wireless and wired, this message pops up:

If I click OK, it seems to work fine, but the point was to have no user interaction at all.

The certificate and the chains seems to be ok:

Why does this pop up?

Is there a way to avoid this?

Are there some flags missing in the certificate?

Can we configure every thing about 802.1x authentication in clients from, say, Active Directory Group Policies?

First I tried to set this up by buying a Certificate from  Godaddy.com, since they are certified.

I installed it under System  Administration > Configuration > Local Server Certificates >  Local Certificates.

But exactly the same popup and result there.

Is it this way it is supposed to be?

Isn't the point with buying Certificates and / or Autoenrollment to have no user interaction at all?

What could be wrong?

Thanks.

[andypalfrey]

I assume from the screenshots you're using the XP native .1x supplicant

Have you defined the Trusted Root Certification Authorities on the client devices interface? The client needs to know which CAs to trust when validating the server certficate

Note also the following from http://support.microsoft.com/kb/814394

Server certificate requirements

You can configure clients  to validate server  certificates by using the Validate server  certificate

option on the Authentication tab in the  Network Connection properties. When a client uses   PEAP-EAP-MS-Challenge Handshake Authentication Protocol (CHAP) version 2  authentication, PEAP with EAP-TLS authentication, or EAP-TLS  authentication, the client accepts the server's certificate when the  certificate meets the following requirements:

• The computer certificate on the server  chains to one of the  following:
  • A trusted Microsoft  root CA.
  • A Microsoft   stand-alone root or third-party root CA in an Active Directory domain  that has an NTAuthCertificates store that contains  the published root  certificate.  For more information about how to import third-party CA certificates,  click the following article number to view the article in the Microsoft  Knowledge Base:
    295663                              (http://support.microsoft.com/kb/295663/                         ) How to import third-party certification authority (CA) certificates  into the Enterprise NTAuth store
• The IAS or the VPN server computer certificate  is configured with the Server Authentication purpose. The object  identifier for Server Authentication is 1.3.6.1.5.5.7.3.1.
• The computer certificate does not fail any one of the checks  that are performed by the CryptoAPI certificate store, and it does not  fail any one of the requirements in the remote access policy.
• The name in the Subject line of the server certificate matches  the name that is configured on the client for the connection.
• For wireless clients, the Subject Alternative Name  (SubjectAltName) extension  contains the server's fully qualified domain  name (FQDN).
• If the client is configured to trust a server certificate with a  specific name, the user is prompted to make a decision about trusting a  certificate with a different name. If the user rejects the certificate,  authentication fails. If the user accepts the certificate, the  certificate is added to the local computer trusted root certificate  store.

Hope that helps

Andy