DOCSLIB.ORG

GLOBALSIGN and RSA SECURITY ANNOUNCE STRATEGIC PARTNERSHIP to ESTABLISH TRUSTED E-TRANSACTIONS Submitted By: Bluegrass Marketing Communications Friday, 15 June 2001

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
GLOBALSIGN and RSA SECURITY ANNOUNCE STRATEGIC PARTNERSHIP to ESTABLISH TRUSTED E-TRANSACTIONS Submitted By: Bluegrass Marketing Communications Friday, 15 June 2001 GLOBALSIGN AND RSA SECURITY ANNOUNCE STRATEGIC PARTNERSHIP TO ESTABLISH TRUSTED E-TRANSACTIONS Submitted by: Bluegrass Marketing Communications Friday, 15 June 2001 GlobalSign, a leading Trust Services Provider for Internet-based transactions, and RSA Security Inc. (NASDAQ: RSAS), the most trusted name in e-security™, today announced they have signed a strategic partnership to offer organisations using RSA Keon® Certificate Authority software a CA Root Signing Service, GlobalSign RootSign. This partnership will enable organisations to establish and conduct trusted e-business transactions with their customers and partners. The RSA Keon CA Root Signing Service is designed to allow an organisation’s CA Root Certificate to chain to an established trust hierarchy that is recognised by major Web browsers and other related PKI-enabled applications. The partnership opens huge perspectives for GlobalSign, as RSA Keon CA software is one of today’s most successful CA-products for securing Internet and e-business applications. Through this relationship, customers using RSA Keon Certificate Authority software (e.g. EDS, ABB Germany,…) can have their CA's Root Certificate signed by GlobalSign and chained to GlobalSign’s publicly recognised trusted root. By using this service, RSA Keon customers can ensure that certificates generated and issued by their RSA Keon Certificate Authority will be automatically validated - and therefore trusted - by popular Web browsers, e-mail packages and other applications that leverage the recognised issuer lists of these Web browsers. “GlobalSign is an established worldwide Trust Services Provider and we are pleased to partner with the industry’s leader in security solutions to offer organisations a trusted method of conducting business transactions on the Internet,” said Henry Minassian, managing director at GlobalSign. “With RootSign, RSA Keon CA customers will be equipped for conducting online business in a fully trusted environment.” “The partnership with GlobalSign is designed to enable organisations worldwide to issue ubiquitously trusted end user certificates,” said Scott Schnell, senior vice president of marketing and corporate development at RSA Security. “By collaborating with GlobalSign, we have added another option for our customers to choose from when planning their PKI deployments. RSA Keon Certificate Authority customers can continue to issue certificates under their private branded root, or now under a publicly recognised root, while still maintaining their brand.” Page 1 About GlobalSign RootSign Public and corporate CAs who don’t have their CA Root embedded into popular browsers can now chain themselves under GlobalSign's embedded CA Root Certificate through RootSign. The GlobalSign CA Root is in the position to assist other CAs in becoming part of these browsers by root-signing their CA Root. The GlobalSign CA Root is embedded & configured in the following browsers: Netscape Communicator starting from version 4.60.Version and Microsoft I.E. 5.01, Windows 2000, Windows NT 4.0 Service Pack 6. About the RSA Keon PKI Family RSA Keon software is a family of interoperable, standards-based PKI products designed to manage digital certificates and provide an environment for authenticated, private and legally binding electronic communications and transactions. Whether deployed as a robust, standalone certificate authority or a comprehensive PKI solution, the RSA Keon digital certificate management solution is designed to provide a common foundation for securing Internet and e-business applications. About GlobalSign GlobalSign, founded in 1996, is a fast-growing international Trust Services Provider, headquartered in Brussels. GlobalSign is active worldwide as a Certification Authority and offers online services for creating and managing digital certificates for signed/sealed e-mail messaging and for fully authenticated and confidential e-commerce. GlobalSign develops flexible corporate PKI-solutions for all types of companies, and offers certification services such as m-commerce security, trust labels and time stamping. GlobalSign is developing an international Network of Trust throughout Europe, Asia and the Americas. Today, GlobalSign is present in Benelux, France, Germany, UK, Italy, India and Chile, amongst others, and it continually integrates other partners in and outside Europe into this network (currently 20 countries). GlobalSign is also the official Certification Authority for the European Commission and works with strategic partners such as Microsoft, Netscape, IBM Global Network, Siemens and Oracle. GlobalSign’s shareholders are Vodafone Group Plc , Ubizen , ING-Barings, Bruficom, GIMV, Technicom and KBC Bank. About RSA Security Inc. RSA Security Inc., the most trusted name in e-security, helps organisations Page 2 build secure, trusted foundations for e-business through its RSA SecurID® two-factor authentication, RSA BSAFE® encryption and RSA Keon digital certificate management systems. With approximately one billion RSA BSAFE-enabled applications in use worldwide, more than nine million RSA SecurID users and almost 20 years of industry experience, RSA Security has the proven leadership and innovative technology to address the changing security needs of e-business and bring trust to the new, online economy. RSA Security can be reached at http://www.rsasecurity.com RSA, BSAFE, Keon and SecurID are registered trademarks, and The Most Trusted Name in e-Security is a trademark of RSA Security Inc. All other products and services mentioned are trademarks of their respective companies. For more information, please contact: PR Consultants Bluegrass Communications Nick Barrance, Emma Gurd Tel: 01264 323141 Fax: 01264 323251 [email protected] Press Contact GlobalSign Juergen Dierickx Tel: + 32 2 724 3636 Fax: + 32 2 724 3637 [email protected] Analyst Contact RSA Security Karin Kosterlitz Tel: +1 (781) 301-5374 Page 3 Distributed via Press Release Wire (https://pressreleases.responsesource.com/) on behalf of Bluegrass Marketing Communications Copyright © 1999-2021 ResponseSource, The Johnson Building, 79 Hatton Garden, London, EC1N 8AW, UK e: [email protected] t: 020 3426 4051 f: 0345 370 7776 w: https://www.responsesource.com.
Load more

Recommended publications
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Installing Fake Root Keys in a PC
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Royal Holloway - Pure Installing Fake Root Keys in a PC Adil Alsaid and Chris J. Mitchell Information Security Group Royal Holloway, University of London Egham, Surrey TW20 0EX fA.Alsaid, [email protected] Abstract. If a malicious party can insert a self-issued CA public key into the list of root public keys stored in a PC, then this party could potentially do considerable harm to that PC. In this paper, we present a way to achieve such an attack for the Internet Explorer web browser root key store, which avoids attracting the user's attention. A realisation of this attack is also described. Finally, countermeasures that can be deployed to prevent such an attack are outlined. 1 Introduction As is widely known [10], most web browsers (e.g. Microsoft Internet Explorer or Netscape) have a repository of root public keys designed for use in verify- ing digitally signed public key certi¯cates. These public keys are bundled with distributions of the web browser, and are used to verify certi¯cates for applet providers [13]. Speci¯cally, web-sites may download applets to a user PC without the PC user knowing it. Depending on the security settings selected by the PC user, these applets may be executed with or without further checks. Typically, the browser will only execute the applet if the following conditions are satis¯ed. 1. The applet must be digitally signed, and the signature must verify correctly. 2.
    [Show full text]
  • Analysis of SSL Certificate Reissues and Revocations in the Wake
    Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed Liang Zhang David Choffnes Dave Levin Tudor Dumitra¸s Northeastern University Northeastern University University of Maryland University of Maryland [email protected] [email protected] [email protected] [email protected] Alan Mislove Aaron Schulman Christo Wilson Northeastern University Stanford University Northeastern University [email protected] [email protected] [email protected] ABSTRACT Categories and Subject Descriptors Central to the secure operation of a public key infrastruc- C.2.2 [Computer-Communication Networks]: Net- ture (PKI) is the ability to revoke certificates. While much work Protocols; C.2.3 [Computer-Communication Net- of users' security rests on this process taking place quickly, works]: Network Operations; E.3 [Data Encryption]: in practice, revocation typically requires a human to decide Public Key Cryptosystems, Standards to reissue a new certificate and revoke the old one. Thus, having a proper understanding of how often systems admin- istrators reissue and revoke certificates is crucial to under- Keywords standing the integrity of a PKI. Unfortunately, this is typi- Heartbleed; SSL; TLS; HTTPS; X.509; Certificates; Reissue; cally difficult to measure: while it is relatively easy to deter- Revocation; Extended validation mine when a certificate is revoked, it is difficult to determine whether and when an administrator should have revoked. In this paper, we use a recent widespread security vul- 1. INTRODUCTION nerability as a natural experiment. Publicly announced in Secure Sockets Layer (SSL) and Transport Layer Secu- April 2014, the Heartbleed OpenSSL bug, potentially (and rity (TLS)1 are the de-facto standards for securing Internet undetectably) revealed servers' private keys.
    [Show full text]
  • Analysis of SSL Certificate Reissues And
    Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed Liang Zhang David Choffnes Dave Levin Tudor Dumitra¸s Northeastern University Northeastern University University of Maryland University of Maryland [email protected] [email protected] [email protected] [email protected] Alan Mislove Aaron Schulman Christo Wilson Northeastern University Stanford University Northeastern University [email protected] [email protected] [email protected] ABSTRACT Categories and Subject Descriptors Central to the secure operation of a public key infrastruc- C.2.2 [Computer-Communication Networks]: Net- ture (PKI) is the ability to revoke certificates. While much work Protocols; C.2.3 [Computer-Communication Net- of users' security rests on this process taking place quickly, works]: Network Operations; E.3 [Data Encryption]: in practice, revocation typically requires a human to decide Public Key Cryptosystems, Standards to reissue a new certificate and revoke the old one. Thus, having a proper understanding of how often systems admin- istrators reissue and revoke certificates is crucial to under- Keywords standing the integrity of a PKI. Unfortunately, this is typi- Heartbleed; SSL; TLS; HTTPS; X.509; Certificates; Reissue; cally difficult to measure: while it is relatively easy to deter- Revocation; Extended validation mine when a certificate is revoked, it is difficult to determine whether and when an administrator should have revoked. In this paper, we use a recent widespread security vul- 1. INTRODUCTION nerability as a natural experiment. Publicly announced in Secure Sockets Layer (SSL) and Transport Layer Secu- April 2014, the Heartbleed OpenSSL bug, potentially (and rity (TLS)1 are the de-facto standards for securing Internet undetectably) revealed servers' private keys.
    [Show full text]
  • Certificate Transparency Using Blockchain
    Certicate Transparency Using Blockchain D S V Madala1, Mahabir Prasad Jhanwar1, and Anupam Chattopadhyay2 1Department of Computer Science. Ashoka University, India 2School of Computer Science and Engineering. NTU, Singapore Abstract The security of web communication via the SSL/TLS protocols relies on safe distribu- tions of public keys associated with web domains in the form of X:509 certicates. Certicate authorities (CAs) are trusted third parties that issue these certicates. However, the CA ecosystem is fragile and prone to compromises. Starting with Google's Certicate Trans- parency project, a number of research works have recently looked at adding transparency for better CA accountability, eectively through public logs of all certicates issued by certica- tion authorities, to augment the current X:509 certicate validation process into SSL/TLS. In this paper, leveraging recent progress in blockchain technology, we propose a novel system, called CTB, that makes it impossible for a CA to issue a certicate for a domain without obtaining consent from the domain owner. We further make progress to equip CTB with certicate revocation mechanism. We implement CTB using IBM's Hyperledger Fabric blockchain platform. CTB's smart contract, written in Go, is provided for complete reference. 1 Introduction The overwhelming adoption of SSL/TLS (Secure Socket Layer/Transport Layer Security Proto- cols) [4, 33] for most HTTP trac has transformed the Internet into a communication platform with strong measures of condentiality and integrity. It is one
    [Show full text]
  • Public Key Distribution (And Certifications)
    Lecture 12 Public Key Distribution (and Certifications) (Chapter 15 in KPS) 1 A Typical KDC-based Key Distribution Scenario KDC = Key Distribution Center KDC EK[X] = Encryption of X with key K (1) Request|B|N1 (2) E [K |Request|N |E (K ,A)] Ka s 1 Kb s (3) E [K ,A] Kb s A (4) E [A,N ] Ks 2 B Notes: (5) E [f(N )] Ks 2 • Msg2 is tied to Msg1 • Msg2 is fresh/new • Msg3 is possibly old * • Msg1 is possibly old (KDC doesn’t authenticate Alice) • Bob authenticates Alice • Bob authenticates KDC 2 • Alice DOES NOT authenticate Bob Public Key Distribution • General Schemes: • Public announcement (e.g., in a newsgroup or email message) • Can be forged • Publicly available directory • Can be tampered with • Public-key certificates (PKCs) issued by trusted off-line Certification Authorities (CAs) 3 Certification Authorities • Certification Authority (CA): binds public key to a specific entity • Each entity (user, host, etc.) registers its public key with CA. • Bob provides “proof of identity” to CA. • CA creates certificate binding Bob to this public key. • Certificate containing Bob’s public key digitally signed by CA: CA says: “this is Bob’s public key” Bob’s digital PK public signature B key PK B certificate for Bob’s CA Bob’s private SK public key, signed by identifying key CA CA information 4 Certification Authority • When Alice wants to get Bob’s public key: • Get Bob’s certificate (from Bob or elsewhere) • Using CA’s public key verify the signature on Bob’s certificate • Check for expiration • Check for revocation (we’ll talk about this later) • Extract Bob’s public key Bob’s PK B digital Public signature Key PK B CA Public PK Key CA 5 A Certificate Contains • Serial number (unique to issuer) • Info about certificate owner, including algorithm and key value itself (not shown) • info about certificate issuer • valid dates • digital signature by issuer 6 Reflection Attack and a Fix • Original Protocol 1.
    [Show full text]
  • Certificate Transparency Description
    Certificate Transparency Description Certificate Transparency is an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. (q.v. IETF RFC 6962) The objectives are described as: Make it very difficult for a CA to issue a TLS certificate for a domain without the certificate being visible to the owner of that domain. Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued. Protect users from being duped by certificates that were mistakenly or maliciously issued. (q.v. https://www.certificate-transparency.org/what-is-ct) Note that end user TLS clients are not responsible for validating CT logs, all they need to do is enforce a requirement that certificates must have extensions that show that they were issued under these procedures by validating a Signed Certificate Timestamp (SCT) data object presented with the TLS server certificate. Monitors and Auditors have the primary responsibility of detecting anomalous certificates that were never submitted to the logs. According to wikipedia, the implementation status of the standard is as follows: Google launched its first certificate transparency log in March 2013.
    [Show full text]
  • Trust Me, I'm a Root CA! Analyzing SSL Root Cas in Modern Browsers
    Trust me, I’m a Root CA! Analyzing SSL Root CAs in modern Browsers and Operating Systems Tariq Fadai, Sebastian Schrittwieser Peter Kieseberg, Martin Mulazzani Josef Ressel Center for Unified Threat Intelligence SBA Research, on Targeted Attacks, Austria St. Poelten University of Applied Sciences, Austria Email: [pkieseberg,mmulazzani]@sba-research.org Email: [is101005,sebastian.schrittwieser]@fhstp.ac.at Abstract—The security and privacy of our online communi- tected communications is dependent on the trustworthiness cations heavily relies on the entity authentication mechanisms of various companies and governments. It is therefore of provided by SSL. Those mechanisms in turn heavily depend interest to find out which companies we implicitly trust just on the trustworthiness of a large number of companies and governmental institutions for attestation of the identity of SSL by using different operating system platforms or browsers. services providers. In order to offer a wide and unobstructed In this paper an analysis of the root certificates included in availability of SSL-enabled services and to remove the need various browsers and operating systems is introduced. Our to make a large amount of trust decisions from their users, main contributions are: operating systems and browser manufactures include lists of certification authorities which are trusted for SSL entity • We performed an in-depth analysis of Root Certifi- authentication by their products. This has the problematic cate Authorities in modern operating systems and web effect that users of such browsers and operating systems browsers implicitly trust those certification authorities with the privacy • We correlated them against a variety of trust indexes of their communications while they might not even realize it.
    [Show full text]
  • The Trip to TLS Land Using the WSA Tobias Mayer, Consulting Systems Engineer BRKSEC-3006 Me…
    The Trip to TLS Land using the WSA Tobias Mayer, Consulting Systems Engineer BRKSEC-3006 Me… CCIE Security #14390, CISSP & Motorboat driving license… Working in Content Security & IPv6 Security tmayer{at}cisco.com Writing stuff at “blogs.cisco.com” Agenda • Introduction • Understanding TLS • Configuring Decryption on the WSA • Troubleshooting TLS • Thoughts about the Future • Conclusion For Your Reference • There are (many...) slides in your print-outs that will not be presented. • They are there “For your Reference” For Your Reference Microsoft and Google pushing encryption • Microsoft pushing TLS with PFS • Google, FB, Twitter encrypting all traffic • HTTPS usage influencing page ranking on google • Deprecate SHA1, only SHA2+ • Browser Vendors aggressively pushing https • Problems with older TLS versions leading to upgrade of servers to newer protocols and ciphers • Poodle, Freak, Beast, …. Google Search Engine • Google ranking influenced by using HTTPS • http://blog.searchmetrics.com/us/2015 /03/03/https-vs-http-website-ssl-tls- encryption-ranking-seo-secure- connection/ Understanding TLS TLS Versions • SSLv3, 1996 • TLS 1.0, 1999, RFC2246 • TLS 1.1, 2006, RFC4346 • Improved security • TLS 1.2, 2008, RFC5246 • Removed IDEA and DES ciphers • Stronger hashes • Supports authenticated encryption ciphers (AES-GCM) • TLS 1.3, currently Internet Draft Attacks… • POODLE • SSLv3 Problems with Padding, turn of SSLv3 • BEAST • Know issues in CBC mode, use TLS 1.1/1.2 with non-CBC mode ciphers (GCM) • CRIME/BREACH • Compression Data Leak, disable
    [Show full text]
  • The Most Dangerous Code in the World: Validating SSL Certificates In
    The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software Martin Georgiev Subodh Iyengar Suman Jana The University of Texas Stanford University The University of Texas at Austin at Austin Rishita Anubhai Dan Boneh Vitaly Shmatikov Stanford University Stanford University The University of Texas at Austin ABSTRACT cations. The main purpose of SSL is to provide end-to-end security SSL (Secure Sockets Layer) is the de facto standard for secure In- against an active, man-in-the-middle attacker. Even if the network ternet communications. Security of SSL connections against an is completely compromised—DNS is poisoned, access points and active network attacker depends on correctly validating public-key routers are controlled by the adversary, etc.—SSL is intended to certificates presented when the connection is established. guarantee confidentiality, authenticity, and integrity for communi- We demonstrate that SSL certificate validation is completely bro- cations between the client and the server. Authenticating the server is a critical part of SSL connection es- ken in many security-critical applications and libraries. Vulnerable 1 software includes Amazon’s EC2 Java library and all cloud clients tablishment. This authentication takes place during the SSL hand- based on it; Amazon’s and PayPal’s merchant SDKs responsible shake, when the server presents its public-key certificate. In order for transmitting payment details from e-commerce sites to payment for the SSL connection to be secure, the client must carefully verify gateways; integrated shopping carts such as osCommerce, ZenCart, that the certificate has been issued by a valid certificate authority, Ubercart, and PrestaShop; AdMob code used by mobile websites; has not expired (or been revoked), the name(s) listed in the certifi- Chase mobile banking and several other Android apps and libraries; cate match(es) the name of the domain that the client is connecting Java Web-services middleware—including Apache Axis, Axis 2, to, and perform several other checks [14, 15].
    [Show full text]
  • SSL Insight Certificate Installation Guide Deployment Guide | SSL Insight Certificate Installation Guide
    DEPLOYMENT GUIDE SSL Insight Certificate Installation Guide Deployment Guide | SSL Insight Certificate Installation Guide Table of Contents Introduction ....................................................................................................................................................................................................................................3 Generating CA Certificates for SSL Insight ...................................................................................................................................................................3 Importing a CA Certificate and Certificate Chain onto the A10 Thunder SSLi Device .....................................................................5 Installing a Certificate in Microsoft Windows 7 for Internet Explorer..........................................................................................................6 Installing a Certificate in Google Chrome ................................................................................................................................................................10 Installing a Certificate in Mozilla Firefox .....................................................................................................................................................................13 About A10 Networks ..............................................................................................................................................................................................................15
    [Show full text]
  • Certificate Authority Trust List
    Certificate Authority Trust List First Published: January 31, 2020 Certificate Authority Trust List The following is the list of trusted Certificate Authorities embedded in the following devices: Cisco IP Phone 7800 Series, as of release 12.7 Cisco IP Phone 8800 Series, as of release 12.7 For Mobile and Remote Access through Expressway, the Expressway server must be signed against one of these Certificate Authorities. Fingerprint Subject 342cd9d3062da48c346965297f081ebc2ef68fdc C=AT, L=Vienna, ST=Austria, O=ARGE DATEN - Austrian Society for Data Protection, OU=GLOBALTRUST Certification Service, CN=GLOBALTRUST, [email protected] 4caee38931d19ae73b31aa75ca33d621290fa75e C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=A-Trust-nQual-03, CN=A- Trust-nQual-03 cd787a3d5cba8207082848365e9acde9683364d8 C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=A-Trust-Qual-02, CN=A- Trust-Qual-02 2e66c9841181c08fb1dfabd4ff8d5cc72be08f02 C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=A-Trust-Root-05, CN=A- Trust-Root-05 84429d9fe2e73a0dc8aa0ae0a902f2749933fe02 C=AU, O=GOV, OU=DoD, OU=PKI, OU=CAs, CN=ADOCA02 51cca0710af7733d34acdc1945099f435c7fc59f C=BE, CN=Belgium Root CA2 a59c9b10ec7357515abb660c4d94f73b9e6e9272 C=BE, O=Certipost s.a., n.v., CN=Certipost E-Trust Primary Normalised CA 742cdf1594049cbf17a2046cc639bb3888e02e33 C=BE, O=Certipost s.a., n.v., CN=Certipost E-Trust Primary Qualified CA Cisco Systems, Inc. www.cisco.com 1 Certificate Authority
    [Show full text]