In this chapter

Digital Certificates Overview

Understanding Commercial Certificate Authorities

Understanding Certificate Servers

Understanding Authenticode

Authenticode 2.0 Features After Authenticode 1.0 Expiration Upgrading to Authenticode 2.0

Using Secure Client/Server Communications

Secure Channels Server Gated Cryptography CryptoAPI 2.0 Secure Networks Socks Firewall Support Windows NT Server Challenge Response

Configuring Certificates

Root Certificate Authorities Client Certificates Trusted Publishers and Certificate Authorities

Deploying Customized Certificates in User Groups

Locking Down Certificates Managing Certificates for Deployed Browsers

Digital Certificates Overview

Digital certificates are electronic credentials that verify an individual's or an organization's identity on the Web. The identity of the digital certificate owner is bound to a pair of electronic keys that can be used to encrypt and sign digital information, assuring that the keys actually belong to the person or organization specified. (For more background information about digital signatures and certificates, see "Overview: Understanding Trust Management" at the beginning of Part 7.)

Digital certificates contain at least the following information:

• Owner's public key 

• Owner's name or alias 

• Expiration date of the digital certificate 

• Serial number of the digital certificate 

• Name of the certification authority that issued the digital certificate 

• Digital signature of the certification authority that issued the digital certificate 

Digital certificates may also contain other user-supplied information, including:

• Postal address 

• E-mail address 

• Basic registration information (country/region, postal code, age, and gender) 

Digital certificates are authenticated, issued, and managed by a trusted third party called a Certificate Authority (CA). The CA must provide a combination of three essential elements: technology, such as security protocols and standards, secure messaging, and cryptography; infrastructure, including secure facilities, customer support, and redundant systems; and practices, including a defined model of trust and a legally binding framework for subscriber activities and disputes. In short, a CA must be a trusted online service operating 24 hours a day, 7 days a week, on a global basis. In addition to obtaining digital certificates from commercial CAs, you can also implement certificate servers such as Microsoft Certificate Server to provide certificate services for your Web infrastructure. Digital certificates form the basis for secure communication and client and server authentication on the Web. Digital certificates can be used to:

• Encrypt secure communication channels between client machines and the servers on the Web. 

• Verify the identity (user authentication) of clients and servers for secure communication channels between clients and servers on the Web. 

• Encrypt messages for secure Internet e-mail communications. 

• Verify the authorship of Internet e-mail messages. 

• Sign executable code to be downloaded on the Web. 

• Verify the source and integrity of signed executable code downloaded from the Web. 

You can install certificates and configure certificate settings for Internet Explorer to control secure e-mail communications, the downloading of active content, and user authentication for clients and servers. System administrators can use the Internet Explorer Administration Kit (IEAK) Configuration Wizard to specify certificate configurations for the custom packages of Internet Explorer they deploy in user groups. The IEAK Profile Manager can be used to manage certificate configurations for user groups through the automatic browser configuration feature of Internet Explorer.

Understanding Commercial Certificate Authorities

Commercial CAs issue digital certificates verifying the electronic identity of individuals and organizations on the Web. The CAs' primary responsibility is to confirm the identity of those seeking a digital certificate, thus ensuring the validity of the identification information contained in the digital certificate.

CAs do the following types of services:

• Provide, manage, and renew digital certificates. 

• Authenticate the identities of individuals and organizations. 

• Verify the registrations of individuals and organizations. 

• Publish and maintain a Certificate Revocation List (CRL) of all digital certificates that have been revoked by the CA. 

• Handle legal and liability issues for broken security. 

Many commercial CAs offer certificate services for Microsoft products, as well as a wide range of other certificate services. For a current list of CAs who support Microsoft products, visit http://www.microsoft.com/security/  .

Commercial CAs issue various types of digital certificates, such as:

• Personal certificates for individuals to digitally sign communications and assure secure transactions over the Internet and intranet. 

• Client and server certificates for managing secure transactions between clients and servers. 

• Software publisher certificates for individuals who digitally sign their software. 

• Software publisher certificates for commercial software publishers who digitally sign their software. 

CAs can also issue many other types of certificates. Each CA operates within the aegis of its Certification Practices Statement (CPS). It's a good idea to visit the CA's Web site and read the CPS to understand the certificates issued and the CA's operating procedures.

You should consider the following issues when choosing a Certificate Authority:

• Is the Certificate Authority a trusted entity operating a certification practice that can both meet your needs and operate efficiently in your region? Others should immediately recognize your Certificate Authority as a reputable, trustworthy organization. If you choose an authority with a questionable reputation, you run the risk of having users reject your server certificate. 

• Is the Certificate Authority familiar with your organization's business interests? Look for a Certificate Authority from whom you can leverage technical, legal, and business expertise. 

• What type of information will the authority require from you in order to verify your identity? Most Certificate Authorities will require detailed information, such as your identity, your organization's identity, and your official authority to administer the Web server for which you are requesting a certificate. Depending on the level of identification assurance required, a Certificate Authority may require additional information, such as professional affiliations or financial information, and the endorsement of this information by a notary. 

• Does the authority have a system for receiving online certificate requests, such as requests generated by a key manager server? An online system can speed up processing of your certificate requests. 

• With a commercial CA, you have less flexibility in certificate issuance and management. Some CA services and products may not integrate with your existing security model and directory services. 

• Substantial costs can be associated with obtaining a server certificate, especially if you need a high degree of identification assurance. 

Understanding Certificate Servers

Instead of obtaining all digital certificates from commercial CAs, you can implement a certificate server such as Microsoft Certificate Server to manage the issuance, renewal, and revocation of industry-standard digital certificates for your users. You can use these digital certificates in conjunction with servers that support SSL or PCT to build a secure Web infrastructure for the Internet or intranet. For large organizations with complex Web needs, certificate servers can offer many advantages over commercial CAs, including total control over certificate management policies and lower costs.

Depending on your relationship with your users, you can obtain server certificates from a commercial CA or you can issue your own server certificates. For services on your intranet, user trust is normally not an issue, and you can easily configure Internet Explorer to trust server certificates issued by your organization. For services on the Internet, however, users may not know enough about your organization to trust server certificates issued by you. Therefore, you may need to obtain server certificates issued by a well-known, commercial CA to ensure that users trust secure channels on your Internet sites.

Understanding Authenticode

Microsoft Authenticode 2.0 technology is used to identify the publisher of a piece of software and verify that it hasn't been tampered with. Software publishers who obtain a digital certificate from a CA can use Authenticode signing tools to digitally sign their software packages for distribution over the Web. (For more information, see the Microsoft Internet Client Software Development Kit.)

Authenticode is client-side software that watches for the downloading of ActiveX controls, .cab files, Java™ applets, or executable files, and then displays warnings to the user about possible security issues. In addition to these warnings, Authenticode displays certificate information, such as the name included in the digital signature, whether it's a commercial or personal certificate, and the date the certificate expires. This information is presented so that users can make a more informed decision before continuing with the download.

Authenticode works by looking for digital certificates (or the lack thereof) in the files being downloaded. The digital certificate is incorporated in a .cab or .ocx file at the time it is compiled. Part of a certificate is the digital signature — the name of the independent software vendor (ISV). A file containing a digital signature is referred to as signed. 

If a piece of software has been digitally signed, Internet Explorer 4 can verify that the software originated from the named software publisher and that it has not been tampered with. Internet Explorer will display a verification certificate if the software passes the test.

A valid digital signature, though, does not necessarily mean that the software is without problems. It just means that the software originated from a traceable source that you may choose to trust and that the software has not been tampered with since publication. Likewise, an invalid signature does not prove the software is bad or dangerous, but just alerts users to potential dangers and problems.

When a digital signature fails the verification process, Internet Explorer reports the failure, reports why the signature is invalid, and queries users to choose whether to proceed with the download.

Internet Explorer can be configured to take different actions, depending on the status of digital signatures. A signature can be unsigned, signed using valid certificates, or signed using invalid certificates.

For signed or unsigned software, you can configure Internet Explorer to:

• Prevent downloading or running the software from a zone. 

• Download and run the software without user intervention from a zone. 

• Query users to make a choice whether to download or run the software from a zone. 

How you configure Internet Explorer to respond to certificates will depend on various factors, such as the level of trust you have for the security zone where the content originated. If you are deploying Internet Explorer in an organization, you'll also want to consider the level of trust you have for the intended user group and the level of technical expertise the users have. For example, you might trust unsigned software from your intranet, but not trust unsigned active content from the Internet. In that case, you would configure Internet Explorer to automatically download unsigned active content from the intranet without user intervention and prevent the download of unsigned active content from the Internet. For more information about configuring security settings, see Part 7, "Security and Privacy."

Authenticode 2.0

Internet Explorer 3 browsers include Authenticode 1.0, but the client-side technology expired on June 29, 1997. Authenticode 2.0 not only renews security features for Internet Explorer users, but also brings new improvements.

Features

The new time-stamping feature of Authenticode establishes that a given piece of software was properly signed during the valid lifetime of a publisher's certificate. (The reason certificates have a limited lifetime is to prevent giving counterfeiters enough time to crack the code associated with the certificate.)

With Internet Explorer 4, Authenticode 2.0 delivers another new feature to protect Web surfers. Before downloading any potentially hazardous code, Internet Explorer 4 can automatically check to make sure a publisher's certificate has not been revoked. Publishers can have their certificates revoked if they abuse their code-signing agreement; for example, by creating malicious code that harms users' computers.

Plus, the valid-site-check feature verifies that the certificate is valid on the actual Web site where it resides. Based on security settings within the certificate, a certificate may be valid only on a specific site.

After Authenticode 1.0 Expiration

Users who don't upgrade to Authenticode 2.0 won't face new security risks, and signed code that has already been downloaded will continue to work; but users may start receiving warnings that some of the software found on the Internet is not safe to download — even if it has been properly signed by a reputable software publisher.

• If security is set to High: Even if the code has been properly signed and updated, you may be prompted that the code is not safe to download. 

• If security is set to Medium: Even if the code has been properly signed and updated, you may be prompted that the certificate used to sign the code is out-of-date. 

Upgrading to Authenticode 2.0

Microsoft Internet Explorer 4 will be shipping with Authenticode 2.0 support within the box. This upgrade to Authenticode supplies several new features that make running a signed ActiveX control more secure.

This technology can be introduced into Internet Explorer 3 using the Authenticode 2.0 patch made available in June 1997. To install the Authenticode 2.0 patch, users must be running the Windows® 95 or Windows NT® 4.0 operating system and Internet Explorer 3 or later on their computers.

Using Secure Client/Server Communications

Digital certificates can be used for secure communications and user authentication between clients and servers on the Web. With digital certificates, clients can be assured of a server's identity; the server proves its identity by presenting a certificate. A user who connects to a Web site that has a server certificate signed by a trusted authority can be confident that the server is actually operated by the individual or organization identified in the certificate. Similarly, digital certificates enable servers to be confident of a client's identity. When a user connects to a Web site, the server can be assured of the user's identity if the server receives the client certificate.

Secure Channels

The exchange of digital certificates between clients and servers is performed using a secure transmission protocol, such as Secure Sockets Layer (SSL) or Private Communications Technology (PCT). SSL 2.0 supports server authentication only. PCT 1.0 and SSL 3.0 support both client and server authentication. Secure transmission protocols can provide three basic security services:

• Mutual authentication. Verifies the identities of both the server and client through exchange and validation of their digital certificates. 

• Communication privacy. Encrypts information exchanged between secure servers and secure clients using a secure channel. 

• Communication integrity. Verifies the integrity of the contents of messages exchanged between client and server, which ensures that messages have not been altered en route. 

Note Encrypting all traffic between clients and servers using secure channels places a high load on secure clients and servers because all information that is transferred must be encrypted and unencrypted. Therefore, secure channel encryption is normally used only for the transfer of small amounts of sensitive information, such as personal financial data and user authentication information.

Server Gated Cryptography

In situations that require the highest-possible level of security, such as online banking, Server Gated Cryptography (SGC) can be used to provide stronger encryption for the client, but only if the server is authorized to use SGC. A special certificate is required. SGC enables financial institutions with Microsoft Windows NT–based Internet servers to use 128-bit SSL encryption — the industry's toughest-to-crack code.

Some of the key benefits of SGC are:

• Banks and financial institutions can securely conduct financial transactions with their retail customers worldwide without requiring customers to change their standard Web browser or financial software. 

• Microsoft's online banking solutions do not require any special client software. Customers can use standard, off-the-shelf, 40-bit exportable versions of Microsoft Internet Explorer to connect to an SGC server and conduct secure transactions with strong, 128-bit cryptography. 

• SGC is fully interoperable with Netscape browsers and servers. This means that Internet Explorer users will be able to communicate at 128 bits with Netscape servers. 

Enabling SGC

SGC works with standard, off-the-shelf export-version servers and client applications that use an updated Schannel.dll and have an SGC digital certificate. The updated Schannel.dll can be freely downloaded from the Microsoft Web site. End users can enable their Internet Explorer browser for SGC by simply downloading the exportable 128-bit SGC add-on. Banks can enable Internet Information Server (IIS) for SGC if they have the standard, off-the-shelf version of Microsoft IIS 3.0, which is part of Windows NT 4.0. They simply download and apply the patch that will update their Schannel.dll file for IIS 3.0. They can use the KeyManager in IIS 3.0 to generate a request for a certificate, which must then be submitted to an authorized Certificate Authority. Once the certificate has been issued and installed, IIS will be fully SGC enabled and will be able to communicate at 128 bits with SGC-enabled Microsoft and Netscape clients.

Implementing SGC

SGC builds on the standard SSL 3.0 protocol. If the server presents the special SGC certificate, then a 128-bit SSL session is set up; otherwise, a 40-bit session is set up. Just like a normal SSL session, the session keys are destroyed after the session is complete.

Two different implementations of SGC currently exist. Both are described below:

Microsoft's Implementation of Server Gated Cryptography Negotiates the SSL Connection Once. 

• The client sends a normal export (40-bit) client hello to the server. 

• The server responds with a server hello, selecting a 40-bit cipher supported by the client. The server certificate arrives with the server hello. 

• The client examines the server certificate and determines that it is allowed to do "fast" SGC by checking the key usage extensions for the existence of the Microsoft Fast SGC key usage extension (1.3.6.1.4.1.311.10.3.2) and by verifying that the certificate chain is rooted with the Microsoft SGC Root or the VeriSign Class 3 CA. 

• The client ignores the rest of the server hello up to the ServerHelloDone message. 

• The client resets its handshake hashes and sends another client hello, containing all of the ciphers allowed in SGC (that is, 128-bit RC4, and so forth). 

• The server receives the client hello and starts the handshake over again, completing the handshake with full-strength ciphers. 

Netscape's Implementation of Server Gated Cryptography Negotiates the SSL Connection Twice. 

• The client and server do a complete SSL handshake. 

• The client then examines the server certificate to see if it should do SGC. 

• The client then initiates a REDO by sending a client hello immediately after the SSL handshake has completed. The client hello contains the strong ciphers allowed in SGC (that is, 128-bit RCA, and so forth). 

• The second SSL handshake completes with full-strength ciphers. 

Details on SGC Certificates 

Each server certificate may contain an extension listing key usage. Both Netscape and Microsoft clients look in these extensions to determine whether a server is certified for SGC.

If the certificate chain is rooted with the VeriSign Class 3 CA and it contains the Netscape key usage extension (OID 2.16.840.1.113730.4.1), then the client may do the Netscape method of SGC.

If the certificate chain is rooted with the Microsoft SGC certification authority and it contains the Microsoft SGC key usage extension SGC OID (1.3.6.1.4.1.311.10.3.2), then the client may do the Microsoft method of SGC.

To ensure interoperability, Microsoft will produce a special certificate signed by the Microsoft SGC certificate to chain to the VeriSign class 3 CA. This certificate will be installed in the Microsoft SGC solution (Schannel.dll). This will allow VeriSign to issue SGC certificates for use by Microsoft client and server software. Thus:

• If a Microsoft Internet Explorer client connects to a Netscape server with a VeriSign SGC Certificate, Internet Explorer will do Netscape's method of SGC. If Internet Explorer connects to a Microsoft Internet Information Server with a VeriSign SGC Certificate, it will do Microsoft's method of SGC. 

• If a Netscape client connects to a Netscape server with a VeriSign SGC Certificate, or to a Microsoft Internet Information Server with a VeriSign SGC Certificate, it will do Netscape's method of SGC. 

CryptoAPI 2.0

CryptoAPI provides the underlying security services for secure channels and code signing. Through CryptoAPI, developers can easily integrate strong cryptography into their applications. Cryptographic Service Provider (CSP) modules interface with CryptoAPI and perform functions including key generation and exchange, data encryption and decryption, hashing, digital signatures, and signature verification. CryptoAPI is included as a core component of the latest versions of Windows. Internet Explorer 4 will automatically provide this support for earlier versions of Windows.

Secure Networks

Socks Firewall Support

Many corporations provide their employees with access to the Internet through firewalls that protect the corporation from unwanted access. Socks is a standard protocol for traversing firewalls in a secure and controlled manner. Internet Explorer 4 is compatible with firewalls that use the socks protocol. Hummingbird Communications, a leading provider of firewalls, provided this support.

Windows NT Server Challenge Response

Corporations can take advantage of the Microsoft Windows NT Challenge Response (NTLM authentication) that might already be in use on their Windows NT Server network. This enables users to have increased password protection and security while remaining interoperable with their existing Internet information servers.

Configuring Certificates

You'll need to consider three areas of trust when installing and configuring certificates in Internet Explorer 4: root certificates for CAs, client certificates, and trusted publishers and CAs. The dialog boxes you'll use for configuration are the same whether you access them from Internet Explorer, the IEAK Configuration Wizard, or the IEAK Profile Manager.

From Internet Explorer, you access the certificates options from the Content tab.

To open the Content tab from Internet Explorer

1. On the View menu, click Internet Options. 

2. Click the Content tab. 

   
   If your browser does not support inline frames, click here to view on a separate page. 

3. After you finish configuring certificates, click OK or Apply on the Content tab to save the changes to Internet Explorer. 

If you're building custom packages to deploy in user groups, see "Deploying Browsers with Customized Certificates" later in this chapter. If you're using the IEAK Profile Manager to configure certificates, also see "Managing Certificates for Deployed Browsers" later in this chapter.

Root Certificate Authorities

Many CAs have their root certificates already installed in Internet Explorer. You can select any of these installed certificates as trusted CAs for server-user authentication, client-user authentication, secure e-mail, and software publishers.

Some CAs do not have their root certificates in Internet Explorer. If you want to use their services, you'll need to import their root public key into Internet Explorer. Each CA's Web site has instructions on obtaining their root certificate (public key). You can use the IEAK Configuration Wizard and the IEAK Profile Manager to import root certificates. For more information, see "Deploying Browsers with Customized Certificates" and "Managing Certificates for Deployed Browsers" later in this chapter.

To remove certificates or select trusted certificates for Internet Explorer, use the Certificate Authorities dialog box.

To configure root certificates

1. On the Content tab, click Authorities. 

2. In the Certificate Authorities dialog box, select an issuer type from the Issuer Type list. 

    

   Issuer Type list:

   • Server user authentication, to trust digital certificates from servers with digital certificates issued by the selected CAs. 

   • Client user authentication, to trust digital certificates from clients with digital certificates issued by the selected CAs. 

   • Secure e-mail, to trust transactions with other computers with digital certificates issued by the selected CAs. 

   • Software publisher, to trust downloads for software digitally signed by publishers with certificates issued by the selected CAs. 

3. Select or clear check boxes for the listed CAs. 

   Note When you select a CA's root certificates as a trusted CA, you are trusting content from sites, people, and publishers with credentials issued by the CA. 

4. Click Close. 

Client Certificates

You may also want to install client certificates, which are used to authenticate users' computers as clients for secure Web communications. You can use the Client Authentication dialog box to install or remove client certificates for Internet Explorer.

To import client certificates

1. In the Content tab, click Personal. 

    

2. In the Client Authentication dialog box, click Import. 

3. In the Import Personal Certificates dialog box, click Browse, and open the certificate file to import. 

    

4. In the Password box, enter your certificate password. 

5. Click OK. 

6. Click Close. 

Trusted Publishers and Certificate Authorities

To designate a publisher or CA as a trusted publisher or CA for Internet Explorer, use the Security Warning dialog box that appears when you download software from that publisher or CA. Active content that is digitally signed with a valid certificate by trusted publishers or CAs will download without user intervention, unless downloading active content is disabled in the security settings for the security zone. You can also use the Authenticode Security Technology dialog box to remove publishers and CAs from the list of trusted publishers and authorities.

To add a trusted publisher or CA

1. Use Internet Explorer to download signed active content from the publisher or CA. 

2. When the Security Warning dialog box appears, select Always trust software from publisher or CA name. 

3. Click Yes to add the publisher or CA to the list of trusted publishers and CAs. 

To remove a trusted publisher or CA

1. On the View menu, click Internet Options. 

2. In the Content tab, click Publishers. 

3. In the Authenticode Security Technology dialog box, select a publisher or CA from the list of trusted publishers and CAs. 

   
   If your browser does not support inline frames, click here to view on a separate page. 

4. Click Remove. 

5. Click OK. 

Deploying Customized Certificates in User Groups

System administrators can use the IEAK Configuration Wizard to deploy certificate configurations in their organizations. Using the IEAK, you can also build custom packages with specific security settings for different user groups. (For more information, see "Building Custom Packages" in Chapter 36.)

To specify certificate settings using the IEAK Configuration Wizard, use the Site Certificate and Authenticode Settings page. You can either accept the default certificate settings or customize the settings to meet your needs. The options in the IEAK for configuring root certificates authorities, client certificates, and trusted publishers and CAs are similar to those presented in Internet Explorer 4, described in more detail in the "Configuring Certificates" section earlier in this chapter.

To accept the default settings in the IEAK

1. Select Do not customize Certificate Authorities. 

2. Select Do not customize Authenticode Security. 

3. Finish building the custom package. 

To add new root certificates

1. Select Import current Certificate Authorities. 

2. Click Add New Root. 

3. From the Browse dialog box, select the file name of the root certificate file, and click Open. 

To customize trusted certificates

1. Select Import current Certificate Authorities. 

2. Click Modify Settings. 

3. Use the Site Certificates dialog box to remove certificates or to select trusted certificates for each Issuer Type. 

To remove a trusted publisher or CA

1. Select Import current Authenticode Security information. 

2. Click Modify Settings. 

3. Use the Authenticode Security Technology dialog box to remove certificates. 

To add a trusted publisher or CA

1. Use Internet Explorer to download signed active content from the publisher or CA. 

2. When the Security Warning dialog box appears, select Always trust software from publisher or CA name. 

3. Click Yes to add the publisher or CA to the list of trusted publishers and CAs. 

Locking Down Certificates

Once you've built your custom certificate packages, you can also use the IEAK Configuration Wizard to lock down certificate configurations and restrict users from changing certificate settings. After browsers are deployed, you can use the IEAK Profile Manager to lock down certificates for user groups that have automatic browser configuration implemented. (For more information, see "Automatic Browser Configuration" in Chapter 37.)

To lock down certificates

1. In the System Policies & Restrictions page of the IEAK Configuration Wizard or at the IEAK Profile Manager, in the System Policies & Restrictions hierarchy, select Internet Restrictions, and then select the Content object. 

   
   If your browser does not support inline frames, click here to view on a separate page. 

   Note The IEAK Profile Manager is shown here, but the System Policies & Restrictions page of the IEAK Configuration Wizard works similarly. 

2. In the right pane, select Disable changing certificate settings. 

3. Save your changes to the auto-configuration (.ins) file, or finish building the custom package, as appropriate. 

Managing Certificates for Deployed Browsers

To manage certificates for deployed browsers, you can use the IEAK Profile Manager in conjunction with automatic browser configuration. (For more information, see "Automatic Browser Configuration" in Chapter 37.)

You can update certificate settings by opening the auto-configuration (.ins) file in the IEAK Profile Manager and, in the left pane, selecting the Wizard Settings hierarchy, and then selecting the Site Certificates and Authenticode Settings object.

To add new root certificates

1. Select Import current Certificate Authorities. 

2. Click Add New Root. 

3. From the Browse dialog box, select the file name of the root certificate file, and click Open. 

To customize trusted certificates

1. Select Import current Certificate Authorities. 

2. Click Modify Settings. 

3. Use the Site Certificates dialog box to remove certificates or to select trusted certificates for each Issuer Type. 

To remove a trusted publisher or CA

1. Select Import current Authenticode Security information. 

2. Click Modify Settings. 

3. Use the Authenticode Security Technology dialog box to remove certificates. 

To add a trusted publisher or CA

1. Use Internet Explorer to download signed active content from the publisher or CA. 

2. When the Security Warning dialog box appears, select Always trust software from publisher or CA name. 

3. Click Yes to add the publisher or CA to the list of trusted publishers and CAs. 

To save changes to the auto-configuration (.ins) file

• From the File menu, click Save. 

Changes are made to users' configurations as scheduled by automatic browser configuration. You can also lock down certificates so users cannot modify the certificate settings.