3e Technologies International, Inc. FIPS 140-2 Non-Proprietary Security Policy Level 2 Validation 3e-523-F2 & 3e-523-3 Secure Multi-function Wireless Data Points HW Versions 1.0, 1.1, 1.2, 2.0 FW Versions 4.4. Security Policy Version 6.1 April 2011 Copyright ©2010 by 3e Technologies International. This document may freely be reproduced and distributed in its entirety. Version 6.2 FIPS 140-2 Non-Proprietary Security Policy GLOSSARY OF TERMS ................................................................................................. 3  1.  INTRODUCTION..................................................................................................... 4  1.1.  PURPOSE ............................................................................................................... 4  1.2.  SCOPE.................................................................................................................... 5  1.3.  CRYPTOGRAPHIC MODULE DEFINITION ................................................................ 5  2.  PORTS AND INTERFACES ................................................................................... 6  3.  ROLES, SERVICES, AND AUTHENTICATION ................................................ 7  3.1.1.  Roles & Services ........................................................................................... 7  3.1.2.  Authentication Mechanisms and Strength .................................................. 11  4.  SECURE OPERATION AND SECURITY RULES ........................................... 12  4.1.  SECURITY RULES................................................................................................. 12  4.2.  PHYSICAL SECURITY TAMPER EVIDENCE ............................................................ 14  4.2.1  3e-523-F2 .................................................................................................... 14  4.2.2  3e-523-3 ...................................................................................................... 15  5.  SECURITY RELEVANT DATA ITEMS ............................................................ 16  5.1.  CRYPTOGRAPHIC ALGORITHMS ........................................................................... 16  5.2.  SELF-TESTS ......................................................................................................... 17  5.2.1  Power-on Self-tests ..................................................................................... 17  5.2.2  Conditional Self-tests .................................................................................. 17  5.2.3  Firmware Integrity Check by bootloader ................................................... 18  5.3.  CRYPTOGRAPHIC KEYS AND SRDIS .................................................................... 18  Version 6.2 2 FIPS 140-2 Non-Proprietary Security Policy Glossary of terms AP Access Point CO Cryptographic Officer DHCP Dynamic Host Configuration Protocol IP Internet Protocol EAP Extensible Authentication Protocol FIPS Federal Information Processing Standard HTTPS Secure Hyper Text Transport Protocol LAN Local Area Network MAC Medium Access Control PRNG Pseudo Random Number Generator RSA Rivest, Shamir, Adleman SHA Secure Hash Algorithm SRDI Security Relevant Data Item SSID Service Set Identifier TLS Transport Layer Security WAN Wide Area Network WLAN Wireless Local Area Network Version 6.2 3 FIPS 140-2 Non-Proprietary Security Policy 1. Introduction 1.1. Purpose This document describes the non-proprietary cryptographic module security policy for 3e Technologies International‘s wireless universal products, the 3e-523-F2 & 3e-523-3 Secure Multi-function Wireless Data Points (3e-523-F2 & 3e-523-3) (Hardware Versions: HW V1.0, V1.1, V1.2 (3e-523-F2) and V2.0 (3e-523-3); Firmware Versions: 4.4). This document defines 3eTI’s security policy and explains how the 3e-523-F2 and the 3e-523-3 meet the FIPS 140-2 security requirements. The table below lists the hardware version and the CPU version utilized by the hardware. Hardware Version CPU Version V1.0 IXP 420 V 1.1 IXP 425 V1.2 (3e-523-F2) IXP 425 V2.0 (3e-523-3) IXP 425 In the FIPS mode of operation, the modules secure all wireless communications with Wi- Fi Protected Access 2 (WPA2). WPA2 is the approved Wi-Fi Alliance interoperable implementation of the IEEE 802.11i security standard. The modules use the following cryptographic algorithm implementations: • AES • AES-CCM • Triple-DES • SHA-1 • HMAC SHA-1 • FIPS 186 Random Number Generator • RSA The cryptographic module security policy consists of a specification of the security rules, under which the cryptographic module shall operate, including the security rules derived from the requirements of the standard. The Cryptographic Modules meet the overall FIPS 140-2 Level 2 requirement as detailed in the table below. Table 1: Module Security Level Specification Security Requirements Section Level Cryptographic Module Specification 2 Module Ports and Interfaces 2 Roles, Services and Authentication 3 Finite State Model 2 Version 6.2 4 FIPS 140-2 Non-Proprietary Security Policy Physical Security 2 Operational Environment N/A Cryptographic Key Management 2 EMI/EMC 2 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A 1.2. Scope This document covers the secure operation of the 3e-523-F2 and 3e-523-3, including the initialization, roles and responsibilities of operating the product in a secure, FIPS- compliant manner, and a description of the Security Relevant Data Items (SRDIs). The term “product” in this document is used if both the 3e-523-F2 and the 3e-523-3 apply. 1.3. Cryptographic Module Definition The 3e-523-F2 and the 3e-523-3 are devices which consist of electronic hardware, embedded software and an enclosure. For purposes of FIPS 140-2, the module is considered to be a multi-chip standalone product. The modules are physically bounded by the mechanical enclosure, which is protected by tamper evident tape. The physical cryptographic boundary of either 3e-525-F2 or 3e-523-3 is defined to be the entire enclosure of the module. The figure below shows the 3e-523-F2. Figure 1 – 3e-523-F2 Version 6.2 5 FIPS 140-2 Non-Proprietary Security Policy The figure below shows the 523-3. Figure 2 – 3e-523-3 The 3e-523-3 contains the same printed circuit board as a 3e-523-F2, but the PCB is housed in a weatherproof, ruggedized enclosure. The firmware is the same between the 3e-523-F2 and the 3e-523-3. 2. Ports and Interfaces The module provides one RJ45 Ethernet port and two RF antenna ports that connect to the same radio card inside the module. Ethernet port is meant to be plugged into a secure IT environment. Data packets coming in and going out of RF antenna ports are encrypted by AES/AES-CCM depending on configuration. For 523-F2 a. Status output: Ethernet port pins and LED pins b. Data output: Ethernet port pins and serial port pins and RF on antenna ports c. Data input: Ethernet port pins and serial port pins and RF on antenna ports d. Control input: Ethernet port pins and RF on antenna ports Version 6.2 6 FIPS 140-2 Non-Proprietary Security Policy For 523-3 a. Status output: Ethernet port and LED b. Data output: Ethernet port and serial port and RF on antenna ports c. Data input: Ethernet port and serial port and RF on antenna ports d. Control input: Ethernet port and RF on antenna ports The management interface of the Cryptographic Module (CM) uses HTTPS protocol. During the HTTPS session setup, the Cryptographic Module enforces mutual authentication between the web client and CM by requesting and validating the web client’s certificate. The Cryptographic Officer must configure the CM with proper root certificate and OCSP server address to facilitate this mutual authentication between the web client and the CM. 3. Roles, Services, and Authentication The 523-F2 and 523-3 series product variants support user identity based operator authentication. There are total of three roles supported by the modules. Two of which are operator roles and the other role is device role. Any operator user can belong to one of the operator roles. The operator user authenticates to the cryptographic module by using username and password and assumes his role upon successful authentication. The set of services available to each role is defined in this section. 3.1.1. Roles & Services The product supports the following authorized roles for operators: Crypto Officer Role: The Crypto officer (CO) role performs all security functions provided by the product. This role performs cryptographic initialization and management functions (e.g., module initialization, input/output of cryptographic keys and SRDIs, audit functions and user management). The Crypto officer is also responsible for managing other CO users and the Administrator users. The Crypto officer uses a secure mutually authenticated web-based HTTPS connection to configure the products and authenticates to the module using a username and password. Administrator Role: This role performs general product configuration. No CO security functions are available to the Administrator. The Administrator can also reboot the product if deemed necessary. The Administrator uses a secure mutually authenticated web-based HTTPS connection to configure the products and authenticates to the module using a username and password. Version 6.2 7 FIPS 140-2 Non-Proprietary Security Policy Device Role: The purpose of the device role is to describe other devices as they interact with this Cryptographic Module, including: - Other Access Points (connecting in Bridge mode or when the CM is in wireless client mode) - WLAN Client When the product is configured to operate in Access Point/Bridge mode, the other device authenticates to the CM by using: For Wireless client device: The client proves its possession of the 256 bit PMK by performing 802.11i defined 4-way handshake protocol or proves its possession of the same encryption key for the static AES encryption mode. For Bridge device: The bridge device authenticates with the CM by proving the possession of the same encryption key. The key size is 128 for AES_CCM and 128,192 or 256 bit for AES encryption configuration When the product is configured to operate in Wireless Client mode, the other device authenticates to the CM by using: The other device (Access Point) through 802.11i defined 4-way handshake process proves that it has the same 256 bit PMK as the client obtained through EAP-TLS authentication from the RADIUS server, or manually input into the device. The Device Role has access to the following services: For Device Role (WLAN client) Apply Wireless Access Point Security on Data Packet AES 802.11i AES-CCM For Device Role (AP) Apply Wireless Bridge Encryption on Data Packet AES AES_CCM Communicate with Wireless Client AES_CCM AES Version 6.2 8 FIPS 140-2 Non-Proprietary Security Policy The following table outlines the security-relevant cryptographic functionalities that are provided by the “operator” roles (Crypto Officer and Administrator): Table 2 – Operator Role Functionalities Categories Features Operator Roles CryptoOfficer Administrator Default Reset6 Default Reset Zeroize11 Zeroize5 Delete10 Delete4 Show1 Show7 Add3 Add9 Set2 Set8 System Configuration Wireless Access Point • Security AES (128-/192-256-bit) X X X X X 802.11i (AES-CCM) X X X X X Wireless Bridge • Encryption AES_CCM (128 bit) X X X X X X AES (128-/192-256-bit) X X X X X X Wireless Client • Security PSK X X X X X EAP-TLS Private Key X X X X X Private Key Password X X X X X Version 6.2 9 FIPS 140-2 Non-Proprietary Security Policy Categories Features Operator Roles CryptoOfficer Administrator Default Reset6 Default Reset Zeroize11 Zeroize5 Delete10 Delete4 Show1 Show7 Add3 Add9 Set2 Set8 Monitoring / Reports • System Status Security Mode X X Current Encryption X X Mode Bridging encryption X X mode Network Access Logs X X System Administration • Factory X X Defaults • Reboot X X X X (perform self- test) • Operating Select wireless X X X X X operating mode among Mode AP, bridge, AP&bridge, client modes • Upgrade firmware and X X Firmware bootloader if bootloader Upgrade is included in upgrade package. • Change password for X X Password Crypto Officer Change password for X X X X X Administrator Change password X X policy for Crypto Officer Change password X X policy for Administrator The operator can view this setting 2 The operator can change this setting 3 The operator can add a required input. 4 The operator can delete a particular entry 5 The operator can zeroize these keys. 6 The operator can reset this setting to its factory default value. 7 The operator can view this setting Version 6.2 10 FIPS 140-2 Non-Proprietary Security Policy 8 The operator can change this setting 9 The operator can add a required input. 10 The operator can delete a particular entry. 11 The operator can zeroize these keys. 3.1.2. Authentication Mechanisms and Strength The following table summarizes the roles and the type of authentication supported for each role: Table 3 – Authentication versus Roles Role Type of Authentication Authentication Data Crypto Officer ID-based Crypto officers present unique usernames and passwords to log in to the module over HTTPS session. The HTTPS session enforces mutual authentication between the CM and the Web client Administrator ID-based Crypto officers present unique usernames and passwords to log in to the module over HTTPS session. The HTTPS session enforces mutual authentication between the CM and the Web client Device Wireless client static key or 802.11i The possession of PMK or authentication between encryption key, if the PMK is wireless client and CM manually entered to the CM, CM as Access Point the passphrase mode is disallowed. Each wireless client is uniquely identified with its MAC address AP static key or 802.11i authentication between CM The possession of the static and AP (CM in wireless key or the possession of PTK. client mode) Each AP is uniquely identified with its MAC address AP static key between CM and AP (CM in AP mode) The possession of the static key. Each AP is uniquely identified with its MAC address. Version 6.2 11 FIPS 140-2 Non-Proprietary Security Policy The following table identifies the strength of authentication for each authentication mechanism supported: Table 4 – Strength of Authentication Authentication Mechanism Strength of Mechanism Userid and password Minimum 8 characters => 94^8 = 6.096E15 PSK 128 bits => 2^128 = 3.40E38 Shared secret 128 bits => 2^128 = 3.40E38 Bridging static key 128 bits => 2^128 = 3.40E38 4. Secure Operation and Security Rules By factory default, the device is put in FIPS mode with NO security setting, and the radio is turned off. In order to operate the product securely, each operator shall be aware of the security rules enforced by the module and shall adhere to the physical security rules and secure operation rules detailed in this section. 4.1. Security Rules The following product security rules must be followed by the operator in order to ensure secure operation: 1. Every operator (Crypto Officer or Administrator) has a user-id on the product. No operator shall violate trust by sharing his/her password associated with the user-id with any other operator or entity. 2. The Crypto Officer shall not share any key, or SRDI used by the product with any other operator or entity. 3. The Crypto Officer shall not share any MAC address filtering information used by the product with any other operator or entity. 4. The operators shall explicitly logoff by closing all secure browser sessions established with the product. 5. The Crypto officer is responsible for inspecting the tamper evident seals. A compromised tape reveals message “OPENED” with visible red dots. Other signs of tamper include wrinkles, tears and marks on or around the label. 6. The Crypto Officer shall change the default password when configuring the product for the first time. The default password shall not be used. 7. The Crypto Officer shall login to make sure encryption is applied in the device. Version 6.2 12 FIPS 140-2 Non-Proprietary Security Policy 8. The Crypto Officer shall login to make sure the device is in FIPS mode by logging in the Web UI and checking “Security Mode” in the page header. This header is available on every web GUI page. 9. The Crypto Officer shall not use an ASCII passphrase for the 802.11i PSK (Pre- Shared Key with Passphrase). Instead, the Crypto Officer must use either direct 802.11i PSK key input (Pre-Shared Key with Master Key) or EAP-TLS (802.1x) methods. 10. The Crypto Officer shall configure the CM to enforce mutual authentication between the Web Client and CM for remote management over HTTPs. Version 6.2 13 FIPS 140-2 Non-Proprietary Security Policy 4.2. Physical Security Tamper Evidence The difference between the 523-F2 and the 523-3 is that the 523-F2 is intended to be placed into a larger enclosure. The 523-3 has weatherproof enclosure and is a stand- alone unit. Functionally, the two modules operate identically. The material used to cover both modules is production grade and opaque within the visible spectrum. 4.2.1 3e-523-F2 The physical security provided is intended to provide FIPS 140-2 Level 2 physical security (i.e. tamper evidence). The tamper evidence tape is applied at the factory. Crypto Officer should check the integrity of the tape. The picture below shows the physical interface side of 3e-523-F2 enclosure with tamper- evident seals. Figure 3 – 3e-523-F2 with tamper seals Version 6.2 14 FIPS 140-2 Non-Proprietary Security Policy 4.2.2 3e-523-3 The physical security provided is intended to provide FIPS 140-2 Level 2 physical security (i.e. tamper evidence). The figures below show the physical interface sides of 3e-523-3 enclosure with tamper- evident seals. Figure 4 – 3e-523-3 Physical Interface Side 1 Figure 5 – 3e-523-3 Physical Interface Side 2 Version 6.2 15 FIPS 140-2 Non-Proprietary Security Policy 5. Security Relevant Data Items This section specifies the product’s Security Relevant Data Items (SRDIs) as well as the product-enforced access control policy. 5.1. Cryptographic Algorithms The product supports the following FIPS-approved cryptographic algorithms. The algorithms are listed below, along with their corresponding CAVP certificate numbers. 3e Technologies International Inc. 3eTI CryptoLib (User Space Library) Algorithm Implementation 1.0 (RNG only) RNG: #583[1, 2] 3e Technologies International Inc. 3eTI OpenSSL Algorithm Implementation 0.9.7- beta3 Triple-DES: #783[1, 2] AES; #1022[1, 2] SHS: #976[1, 2] RSA: #490[1, 2] HMAC: #571[1, 2] 3e Technologies International Inc. 3eTI CryptoLib (Kernel Module) Algorithm Implementation 1.0 AES; #1021[1] SHS: #975[1] HMAC: #570[1] 3e Technologies International Inc. 3eTI Kernel Accelerated Crypto Core (Hardware) Algorithm Implementation 1.0 AES; #1023[2] SHS: #977[2] HMAC: #572[2] Where [1] represents the IXP 420 CPU and [2] represents the IXP425 CPU The product also supports the following non-Approved but FIPS allowed cryptographic algorithms: • RSA (key wrapping, key establishment methodology provides 80 bits of encryption strength) • MD5 hashing in HTTPS over TLS • AES (Cert. #1021, key wrapping) • Non-Approved RNG Version 6.2 16 FIPS 140-2 Non-Proprietary Security Policy 5.2. Self-tests POST (Power on Self Test) is performed on each boot-time. On-demand self test is provided over the management interface. Crypto Officer User can command or schedule on-demand test from web GUI. 5.2.1 Power-on Self-tests OpenSSL Power-on Self Tests AES ECB - encrypt/decrypt KAT Triple-DES CBC – encrypt/decrypt KAT RSA KAT SHA-1 KAT HMAC-SHA-1 KAT Crypto-1.0 User Library Power-on Self Tests FIPS 186-2 (Appendix 3.1, 3.3) RNG KAT Kernel Crypto Module Power-on Self Tests AES ECB - encrypt/decrypt KAT AES CCM KAT SHA-1 KAT HMAC-SHA-1 KAT Kernel Crypto Coprocessor Power-on Self Tests (Hardware) AES ECB – encrypt/decrypt KAT AES CCM KAT SHA-1 KAT HMAC SHA-1 KAT Software Integrity Power-on Self Tests SHA-1 Integrity Test for firmware SHA-1 Integrity Test for bootloader If any of the Power-on Self-tests fail, the system halts. The operator can attempt to power cycle the module to clear the error condition. Once the error condition has been cleared, the Crypto Officer or Administrator can view the logs to determine the type of failure. 5.2.2 Conditional Self-tests Whenever a firmware package is uploaded through HTTPS over TLS secure channel, the package integrity check is performed before the firmware can be updated. Version 6.2 17 FIPS 140-2 Non-Proprietary Security Policy The firmware package is wrapped in 3eTI proprietary format and HMAC-SHA1 hashed for integrity check. Whenever a random number is generated (both FIPS 186-2 Approved and non- Approved), a Continuous Random Number Generator test is performed to ensure the random number is not repeating. 5.2.3 Firmware Integrity Check by bootloader After device is powered on, the first thing done by bootloader is to check firmware integrity. If the integrity fails, firmware won’t boot. Firmware integrity is also performed at POST (Power On Self Test) during firmware boot up. The bootloader integrity is done at POST, too. 5.3. Cryptographic Keys and SRDIs The module contains the following security relevant data items: Table 5 - SRDIs Non-Protocol Keys/CSPs Key/CSP Type Generation/ Output Storage Zeroization Use Input Operator ASCII string Input Not output Hash value in Zeroized Used to passwords encrypted flash when reset to authenticate (using TLS (PKCS#5) factory CO and session key) settings. Admin role operators Configuration HMAC key Input Not output Plaintext in Zeroized Used for file (ASCII string) encrypted RAM. when a downloaded passphrase (using TLS configuration configuration session key) file is file message by Crypto uploaded after authentication Officer it is used. Firmware load HMAC key Embedded in Not output Plaintext in Zeroized Used for key (ASCII string) firmware at flash when firmware load compile time. firmware is message Firmware upgraded. authentication upgrade is through encrypted (using TLS session key) SNMP packet HMAC key Input Not output Ciphertext in Zeroized Use for authentication (ASCII string) encrypted flash when reset to SNMP keys, (using TLS factory message username session key) settings. authentication RNG Keys/CSPs Key/CSP Type Generation/ Output Storage Zeroization Use Version 6.2 18 FIPS 140-2 Non-Proprietary Security Policy Input FIPS 186-2 20-byte value RNG Seed Not output Plaintext in Zeroized Used to PRNG Seed RAM every time a initialize FIPS Key new random PRNG number is generated using the FIPS PRNG after it is used. RNG Seed 20-byte value 512 bytes Plaintext in Zeroized Used as seed from system RAM every time a for Non- interrupt new random approved numbers number is RNG which hashed by generated provides the HMAC-SHA1 using the seed key for FIPS PRNG the FIPS 186- after it is 2 PRNG. used. 3eTI Static Protocol Keys/CSPs Key/CSP Type Generation/ Output Storage Zeroization Use Input AP / Client AES ECB Input Not output Ciphertext in Zeroized Used to Static key (e/d; encrypted flash when encrypt 128,192,256) (using TLS encryption unicast, and session key) mode is broadcast/ changed or at multitcast factory default traffic in reset time support of static mode IEEE 802.11i Protocol Keys/CSPs (Common to PSK and EAP-TLS) Key/CSP Type Generation/ Output Storage Zeroization Use Input PMK 802.11i Pair- Typed in Not output For 802.11i Zeroized 802.11i PMK wise Master directly as a PSK mode, when Key Hex string. it’s store in authentication Input encrypted mode is encrypted mode in flash changed using the TLS session key. For both If 802.11i 802.11i PSK PSK, zeroized If 802.11i and EAP-TLS, when reset to EAP-TLS, plaintext in factory then not input, RAM settings. instead derived (TLS master secret resulting from successful User EAP- TLS authentication ) PTK AES (key Not input Not output Plaintext in When 802.11i 802.11i PTK derivation; (derived from RAM session ends. 256) PMK) KCK HMAC key Not input Not output Plaintext in When 802.11i 802.11i KCK (128 bits from (derived from RAM session ends. PTK) PTK) Version 6.2 19 FIPS 140-2 Non-Proprietary Security Policy KEK AES ECB(e/d; Not input Not output Plaintext in When 802.11i 802.11i KEK 128) (derived from RAM session ends. PTK) TK AES CCM Not input Not output Plaintext in When 802.11i 802.11i TK (e/d; 128) (derived from RAM session ends. PTK) TK (copy in AES CCM Not input Not output Plaintext in When 802.11i 802.11i TK driver) (e/d; 128) (derived from RAM session ends. PTK) GMK AES (key Not input Not output Plaintext in Zeroized 802.11i GMK derivation; (RNG) RAM when 256) authentication mode is changed When re-key period expires GTK AES CCM Not input Output Plaintext in Zeroized 802.11i GTK (e/d; 128) (derived from encrypted RAM when GMK) (using KEK) authentication mode is chagned When re-key period expires 3eTI Security Server Keys/CSPs Key/CSP Type Generation/ Output Storage Zeroization Use Input Security HMAC key Input Not output Ciphertext in Zeroized Authenticate Server (ASCII string) encrypted flash when module to password (using TLS authentication Security session key) mode changes Server in support of Zeroied when 802.11i EAP- reset to TLS factory default authentication Backend HMAC key Input Not output Ciphertext in Zeroized Authenticate password (ASCII string) encrypted flash when messages (using TLS authentication between session key) mode changes module and security server Zeroied when in support of reset to 802.11i EAP- factory default TLS AES Key AES ECB key Input Not output Ciphertext in Zeroized Decrypt TLS Wrap key (d;128) encrypted flash when master secret (using TLS authentication returned to session key) mode changes module by Security Zeroied when Server after reset to successful factory default User authentication in support of 802.11i EAP- TLS 3eTI Bridging Protocol Keys/CSPs Version 6.2 20 FIPS 140-2 Non-Proprietary Security Policy Key/CSP Type Generation/ Output Storage Zeroization Use Input Bridging static AES ECB Input Not output Ciphertext in Zeroized Used to key (e/d; encrypted flash when bridge encrypt 128,192,256) (using TLS encryption bridged traffic session key) mode is between two changed modules RFC 2818 HTTPS Keys/CSPs Key/CSP Type Generation/ Output Storage Zeroization Use Input RSA private RSA (1024) Not input Not output Plaintext in Zeroized Used to key (key (installed at flash when support CO wrapping; key factory) firmware is and Admin establishment upgraded. HTTPS methodology interfaces. provides 80- bits of encryption strength) TLS session Triple-DES Not input, Not output Plaintext in Zeroized Used to key for (192) derived using RAM when a page protect encryption TLS protocol of the web HTTPS GUI is served session. after it is used. The following table lists cryptographic keys and key material that are unique to the product when it is operating in wireless Client mode: Table 6 – SRDIs in Client Mode Type ID Storage Location Form Zeroization Certificate Authority Zeroized when a Plaintext (CA) public key “CA public key” FLASH new certificate is (inaccessible) certificate uploaded Client public key Wpaclt.der FLASH Plaintext Zeroized when a certificate new certificate is uploaded Client private key RSA Wpaclt.pem FLASH Plaintext Zeroized when a 1024 new certificate is uploaded Version 6.2 21