The following requirements must be fulfilled for the service's certificate:

1. Certificate must be installed in the Personal folder of the LocalMachine store.
   
2. Certificate must have private key.
   
3. Certificate must be trustworthy, i.e. the issuer of the X.509 certificate in the certificate chain is in the Trusted Root Certification Authorities. 
   
4. The account under which the ASP.NET process (ASPNET user by default) is running must have access granted to this certificate.
   
5. Certificate must be exported (without private key!) to all the clients that will use Secure Access Web Service and stored in their Current User (My user account) certificate store.
   
   

Read the following chapters for details:

                                 i.            R ead Managing X.509 Certificates chapter.

                                ii.            I f you decide to install your own certification service, then follow these chapters:

Set Up Your Own Certificate Service
Generate Service Certificate Using Your Own Certificate Service

Otherwise, obtain service certificate from some public Certificate Authority, such as Verisign.

For testing purposes, you may use test certificates delivered together with SecureAccess application, see Sample Application - a Step-by-Step Guide  chapter for details.

                              iii.            S et up access rights so that the ASP.NET process can access the service certificate, as described in the Managing X.509 Certificates chapter, in paragraphs "Required Permissions for the WSE to Sign or Decrypt with an X.509 Certificate" and "Required Permissions for the WSE to Sign or Decrypt with an X.509 Certificate".

After you fulfill the requirements, please follow these steps:

1. Configure the Web Service by updating settings in the Web.config file.
   
              Parameters in the <appSettings> section:
   
   

                                    i.            SecureAccessServiceCertKeyID - if you decide to use X.509 certificates for securing the client-service communication (as mentioned in the previous step), it is necessary to specify the Subject Key Identifier of the privaertificate here. The service will use the certificate for signing responses and verifying that the incoming requests were encrypted using service public certificate; the value must be 20 bytes long hexadecimally encoded value. You can obtain this value directly from the Certificates snap-in Management Console (MMC).
   

                                   v.            SecureAccessRuleSymmetricEncryptionRequired -  indicates whether the symmetric encryption is required for both incoming and outgoing messages. If it's set to true, requests that are not symmetrically encrypted will be refused. Possible values are "true" or "false".
   

                                 vi.            SecureAccessRuleX509SignatureRequired -  indicates whether the X.509 signature is required for both incoming and outgoing messages. If it's set to true, requests that are not signed will be refused. Possible values are "true" or "false".
   
   

                               vii.            SecureAccessRuleX509EncryptionRequired -  indicates whether the X.509 encryption is required for both incoming and outgoing messages. If it's set to true, requests that are not encrypted using public key of the service certificate will be refused. Possible values are "true" or "false".

   
   Note: If the X.509 encryption is required, it is necessary that the requests contain X.509 signature; Web Service extracts the client's public key from this signature and uses it for en
   crypting the response.
   

   Attributes in the <x509> section:
   

   a.       storeLocation - specifies where the WSE searches for X.509 certificates when it attempts to retrieve or verify a certificate. Typically, a client application sets the storeLocation attribute to "CurrentUser" and an XML Web service sets it to "LocalMachine". The default is "LocalMachine".

   b.       verifyTrust - Specifies whether the WSE verifies that X.509 certificates used to sign a message have an issuer chain that extends to a trusted root authority. The default is "true". 

   c.        allowTestRoot - Specifies whether the WSE modifies the trust verification process to allow X.509 certificates signed by a test root to pass the verification. The default value is "false".

   d.       allowRevocationUrlRetrieval - Specifies whether the WSE modifies the trust verification process to allow X.509 certificates signed by a test root to pass the verification. The default is "false".

   e.        allowUrlRetrieval - Specifies whether the WSE does URL retrieval during certificate trust chain construction. When this attribute is set to false, only cached URLs are used in building a certificate trust chain, and the WSE does not access the network to do any URL retrieval. The default value is false.

2. The Secure Access Web Service should be working now. Please continue with configuration of the client.
3. You can verify that the ARWebService has been configured correctly by running test sample called SampleARWSTestFormVB.exe. Delete the values for the following Encrypting Symmetric Key if your client and server is not configured for symmetric cryptography, enter the correct catalog name, login and password and click Try Login. You should get be the confirmation or detailed error message.