{"product_id":4024,"v_id":4024,"product_name":"Microsoft Certificate Server 2003","certification_status":"Not Certified","certification_date":"2005-11-15T00:11:00Z","tech_type":"Certificate Authority","vendor_id":{"name":"Microsoft Corporation","website":"https://www.microsoft.com"},"vendor_poc":"Tim Myers","vendor_phone":"+1 425-882-8080","vendor_email":"wincc@microsoft.com","assigned_lab":{"cctl_name":"Leidos Common Criteria Testing Laboratory"},"product_description":"<p>The Microsoft Windows Server 2003 Certificate Server (henceforth referred to as Certificate Server) is a Certificate Issuing and Management Component (CIMC) that facilitates the use of public key cryptography by issuing, revoking, and managing public key certificates and certificate status information. To achieve this goal, Certificate Server implements the following core functional components:</p>\r\n<ul>\r\n    <li>Policy-based generating and distributing Public Key (including X.509) Certificates to bind user public keys to other information after validating the accuracy of the information provided\r\n    <ul>\r\n        <li>Certificate Enrollment or Request based on\r\n        <ul>\r\n            <li>PKCS #7 (Cryptographic Message Syntax Standard), </li>\r\n            <li>PKCS #10 (Certification Request Syntax Standard), </li>\r\n            <li>RFC 2797 CMC (Certificate Management Messages over Cryptographic Message Syntax) </li>\r\n        </ul>\r\n        </li>\r\n        <li>Certificate Renewal </li>\r\n        <li>Certificate Revocation </li>\r\n        <li>Certificate Retrieval </li>\r\n        <li>Request Pending Management </li>\r\n    </ul>\r\n    </li>\r\n    <li>Maintaining and distributing certificate status information for unexpired certificates\r\n    <ul>\r\n        <li>Certification and Certificate Revocation List (CRL) Management </li>\r\n    </ul>\r\n    </li>\r\n    <li>Certificate database backup and restore </li>\r\n    <li>Security configuration and management of Certificate Server </li>\r\n</ul>\r\n<p>Certificate Server comprises executables and dlls that implement certificate issuance enforcement, certificate and CRL publication, a database manager, and several Microsoft Management Console (MMC) snap-ins (Certificate Authority, Certificate Server, and Certificate Template). To interact with the services of the aforementioned functional components, Certificate Server provides authorized users of different roles with Graphic User Interface based and command-line based tools that can be executed remotely or locally.  These tools use the underlying network based programmatic interfaces implemented by the TOE.  This set of programmatic interfaces is able to support automatic certificate enrollment for both user and computer accounts defined for a distributed Windows Operating System environment within the same network of the TOE.</p>\r\n<p>Certificate Server is available on server class hardware running Microsoft Windows Server 2003 Enterprise Edition (32-bit) Operating System software. Additionally, Certificate Server must be installed in the Enterprise mode.</p>","evaluation_configuration":null,"security_evaluation_summary":"<p>The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme. The criteria against which the Microsoft Windows Server 2003 Certificate Server TOE was judged are described in the Common Criteria for Information Technology Security Evaluation, Version 2.1.  The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 1.0.  Science Applications International Corporation (SAIC) determined that the evaluation assurance level (EAL) for the product is EAL 4 with the additional augmentation of the CC Flaw Remediation (ALC_FLR) family of assurance requirements.  The product, when configured as specified in the Windows Server 2003 Certificate Server Security Configuration Guide (version 1.0), satisfies all of the security functional requirements stated in the Windows Server 2003 Certificate Server Security Target (Version 1.0) and is conformant to the CIMC SL 3 PP. Three validators on behalf of the CCEVS Validation Body monitored the evaluation carried out by SAIC.  The evaluation was completed in November 2005.  Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report, (report number CCEVS-VR-05-0134, dated 14 November 2005) prepared by CCEVS.  The guidance documentation can be downloaded from <a href=\"http://www.microsoft.com/technet/security/prodtech/windowsxp/ccc/default.mspx\">http://www.microsoft.com/technet/security/prodtech/windowsxp/ccc/default.mspx</a>.</p>","environmental_strengths":"<p>The logical boundaries of Certificate Server can be characterized as the set of security functions available at its physical interfaces. Each of these security functions is summarized below.</p>\r\n<ul>\r\n    <li><strong>Identification</strong> &ndash; Certificate Server, in conjunction with the IT Environment, ensures that users are identified before they can access any other security relevant services. All local or remote communications with the TOE are completed over Kerberos-enabled secure DCOM (Distributed Component Object Model) channels which require the client to be known to the IT Environment prior to allowing the communication channel to be established. The IT Environment enforces the identification and authentication prior to allowing any security services to be available to users </li>\r\n    <li><strong>Access Control</strong> &ndash; Certificate Server enforces user roles and access control whenever users access its services. To enforce its security policy, Certificate Server enforces roles through the use of IT Environment policies and Certificate Server managed Access Control Lists (ACL). IT Environment administrators are responsible for assigning users IT Environment policies and Certificate Administrators are responsible for defining the access control lists maintained by the Microsoft  Certificate Server. Access Control is primarily enforced by ensuring a user is mapped to a role before any security relevant operation is performed. </li>\r\n    <li><strong>Roles</strong> &ndash; Certificate Server uses the access control functions to control the actions of administrative personnel. In order to accomplish this, predefined access control lists are assigned to the applicable services. </li>\r\n    <li><strong>Role Separation &ndash; </strong>When role separation is enabled, which is required in the evaluated configuration, Certificate Server does not allow any user account to be assigned to more than a single role. Certificate Server enforces the actions for each role to be performed by accounts that have been assigned that specific role. The following roles are defined:<strong></strong> </li>\r\n    <li>Certificate Administrator </li>\r\n    <li>Officer </li>\r\n    <li>Auditor </li>\r\n    <li>Backup Operator </li>\r\n    <li>Enrollee. </li>\r\n    <li><strong>Security Audit</strong> &ndash; By using the auditing infrastructure of the IT Environment, Certificate Server has the capability to generate audits for security relevant events associated with the services that it provides.  Certificate issuance and management related audit records (including the responsible user, date, time, and other details) are generated when their associated audit events occur inside Certificate Server. Certificate Server tracks actions taken to a certificate (creation, revocation, publication, request pending, and request denial), changes to user&rsquo;s roles and access, certificate database backup and restore operations, and modifications to the TOE configuration.  After receiving the audit records from Certificate Server, the IT Environment audit infrastructure protects them, together with other IT Environment security relevant audit records, in its in-memory audit queue.  Concurrently, the IT Environment empties its audit queue by writing the queue elements to a persistent audit log file that it has opened executively for its own access only during system boot. </li>\r\n    <li><strong>Backup and Recovery &ndash; </strong>Certificate Server has a backup/restore service for its certificate database that can be used by an authorized user to save a snapshot of it and then restore the certificate database at a later date. </li>\r\n    <li><a name=\"_Toc70738979\" id=\"_Toc70738979\"><strong>Remote Certificate Request Data Entry &amp; Certificate and Certificate Status Export</strong></a> &ndash; Certificate Server processes certificate requests formatted according to the following standards which provide the verification of origin framework for the TOE to follow: </li>\r\n    <li>PKCS #7 (Cryptographic Message Syntax Standard) </li>\r\n    <li>PKCS #10 (Certification Request Syntax Standard) </li>\r\n    <li>RFC 2797 CMC (Certificate Management Messages over Cryptographic Message Syntax). </li>\r\n</ul>\r\n<p>Certificate Server generates certificates according to the following standard which provides a verification of origin framework for users of certificates:</p>\r\n<ul>\r\n    <li>RFC 3280 Internet X.509 Public Key Infrastructure Certificate and CRL Profile. </li>\r\n</ul>\r\n<p>The CRLs generated by the TOE are in a format specified in RFC3280 with the following exception: the critical Issuing Distribution extension is not asserted in specific circumstances when the CRL does not cover certificates where the CA key signing the certificates is different from the CA key signing the CRL. Thus, the CRL should be used only by those relying parties that require the certificate and CRL to be signed using the same key. Alternatively, the Certificate Server should be operated so that a CA is never re-keyed. When there is a need to stop using the CA key, a new CA with a new Distinguished Name and a new Key is created.</p>\r\n<ul>\r\n    <li><strong>Key Management &ndash; </strong>Certificate Server uses a hardware cryptographic service module in the IT environment for a number of key management functions. In particular, security critical keys and other information are protected by either encrypting them or storing them within the hardware cryptographic service module. Digital signatures are used when appropriate to ensure the integrity of key management related information.<strong></strong> </li>\r\n    <li><strong>Certificate Management &ndash; </strong>Certificate Server includes a number of certificate management functions. In particular, administrators can control, limit, or mandate values in certificates and certificate revocation lists (CRLs).<strong></strong> </li>\r\n    <li><strong>Certificate Templates for Certificate Profile Management &ndash; </strong>Certificate templates define the attributes for certificate types. Authorized users can configure Certificate Server to issue specific certificate types to authorized users and computers. When Certificate Server creates a certificate, a corresponding certificate template is used to specify its attributes, such as the authorized uses for the certificate, the cryptographic algorithms that are to be used with it, the public key length, and the certificate lifetime. Certificate templates are stored in Active Directory and provide information for each of the certificate types.  Certificate Server queries the Active Directory for the set of templates that it uses for issuing certificates. A number of pre-configured, commonly used certificate templates are available.<strong></strong> </li>\r\n    <li><a name=\"_Toc70738983\" id=\"_Toc70738983\"><strong>Qualified Subordination</strong></a><strong> &ndash; </strong>Qualified subordination allows cross-certification of CA certificates with constraints (name and policy constraints) and provides for more granular control of certificate trusts.  With qualified subordination an authorized administrator can also include or exclude certificate purposes (through the use of a Microsoft private extension: application policies). In order for a certificate to be acceptable for an application, the application policy OID (if present) must be present in all the certificates in the certificate chain.  Thus, for example, through the use of application policies, qualified subordination can be formed to reject IPSec usage with a third (3rd) party certificate but allow secure email with the same certificate even if the certificate&rsquo;s extended key usage and application policies would allow IPSec and secure email.<strong></strong> </li>\r\n</ul>\r\n<p><strong>Support for Auto-Enrollment &ndash; </strong>As Active Directory can define the permission for a specific account to enroll to a certificate template, the use of certificate templates in Certificate Server allows automatic certificate issuing based on the certificate profile information contained in a particular certificate template that a certificate requester has permission to enroll to.</p>","features":[]}