• Removal of Root Certificate PCA3-G1

        Dec 15 2015, 6:33 PM

        by Unknown 1

        Like all large Certificate Authorities, at Symantec we routinely evaluate whether certain public root certificates should continue to be in use, or repurposed for other non-browser facing applications.  When that happens, we make formal requests to the major browsers and OS trust store providers to remove, or at least “un-trust” the root for securing websites.

        In the last few years, we’ve been laying the groundwork with customers that root certificate PCA3-G1 was nearing the end of its life. In November, we followed up with several browsers still using it to let them know that it’s now time to remove or “un-trust” our PCA3-G1 root. We take care to ensure that the removal or “un-trusting” of any root will cause no harm or undue risk to the Internet ecosystem, particularly browser users.

        While this root no longer makes sense for major browsers there are a number of enterprise customers who do rely on it. To serve their needs, we will reuse the root certificate in our private TLS offering for enterprise customers who have requested certificates for legacy software and legacy devices that sit behind corporate networks. Our records and public scans show that all customers have migrated away from using this root for any public use, and our testing leads us to believe that its removal poses no risk to browser users.

        The recent flurry of conversation within the CA community about untrusting roots has opened our eyes to the need for more dialogue. Moving forward, you can expect to see regular posts from us. Our hope is it will spark open industry debate where we can all share ideas that will benefit anyone with an interest in website security.

        • browser
        • Products
        • website security solutions
        • DigiCert Code Signing
        • Root
        • Symantec Website Security
      • Ensuring compatibility without compromising security: the case of ECC/RSA hybrid certificates

        Mar 29 2018, 10:33 PM

        by Charlotte Pommier 0

        We have talked a lot about ECC (Elliptic Curve Cryptography) for the past year. Although the use of elliptic curves is not exactly new, their use in our industry is fairly recent: ECC is a new cryptographic algorithm used for key exchange and authentication purposes in the SSL/TLS protocols (see this previous blog article for more details). 

        It is expected that RSA – the current standard - will be replaced by ECC as its scalability is becoming an issue with the arrival of IoT (Internet of Things):  explosion in number of devices, machine to machine (M2M) communications, ever-growing amount of data transfers, etc.

        We expected this change to happen. This is why Symantec’s ECC roots have been added to all major root stores back in 2007. Most CAs followed years later.

        ECC, RSA and compatibility

        The reliability and performances of ECC no longer need to be demonstrated. However, a significant obstacle to the adoption of ECC lies on the lack of support for this relatively new algorithm in legacy products.  While all modern servers and browser fully support ECC, some legacy system will not trust ECC roots, or will not be able to support ECC at all.

        Browser compatibility (root ubiquity) as of today

        Client ECC Support Pure ECC ECC & RSA Hybrid
        PC Windows XP or older Not supported Not supported
          Windows Vista or newer Supported Supported
          Mac OSX V10.9 or newer V10.6 or newer
        Mobile Android Android 3.x or newer Android 4.0 or newer
          iOS iOS 7.x or newer iOS 3.x or newer
        Ecosystem Server to Server Depends on the customer environment Depends on the customer environment

        Current Server compatibility as of today

        Vendor Product ECC CSR ECC cert install
        Microsoft Win Server 2008 (IIS 7.0) or newer Supported Supported
        Apache, nginx OpenSSL 1.0.1e Supported Supported
        Oracle Sun Java System Web Server 7.0 Supported Supported
        F5 11.5 or newer Supported Supported
        IBM HTTP Server 8.0 + PM80235 Supported Supported
        Citrix Netscaler Not Supported Not Supported

        There are devices and systems that are unable to proceed with ECC due to a trust deficit due to the missing trusted ECC root certificate and it is not always possible to upgrade, change servers or switch to another application easily. To overcome this issue, Symantec has created a solution for devices and systems that can support ECC but don’t have ECC roots in their trust stores: hybrid ECC/RSA hybrid SSL certificates.

        Hybrid certificates use ECC for encryption and authentication but are chained to a well-trusted RSA root. Hybrid ECC/RSA certificates enable you to benefit from the best protection for your current infrastructure and mitigate potential compatibility issues at the same time.

        How does it work?

        It’s fairly simple: when you enroll, we give you the choice between a full ECC certification chain (fig.1) and a hybrid ECC/RSA certification chain (fig.2). The full ECC chain comprises of your ECC SSL certificate, signed by an ECC intermediate, signed by an ECC root.

        ECC - RSA chains-01.jpg

        Fig. 1:full ECC chain

        In order to offer hybrid RSA/ECC certificates, we have created a new ECC intermediate signed by an RSA root. This intermediate can be installed as direct intermediate, or as a cross certificate to a full ECC chain.

        The direct intermediate is the solution we recommend. You benefit from ECC encryption for your infrastructure, while using a globally trusted RSA root.

        ECC - RSA chains-02.jpg

        Fig.2: hybrid ECC/RSA chain

        If you are unsure which certification path is made for you, or if you have questions or concerns, please contact us! We are happy to help and to advise.

        • Products
        • website security solutions
        • DigiCert SSL TLS Certificates
        • Products and Solutions
      • Raising the Bar for Security and Trust on the Web

        Sep 11 2015, 7:38 PM

        by Brook Chelmo 1

        Recently, Symantec updated its certificate issuance controls to pay special attention to domains flagged for excessive abuse, malware, spam, and other suspicious activity.  We recently received intelligence that .PW domains had a history of suspicious and abusive behavior.  After further analysis, we decided to place a hold on issuing minimally-authenticated Domain Validated SSL/TLS certificates and are instituting a policy of only offering the stronger authenticated Organization and Extended Validation SSL/TLS certificates to .PW domains.  Part of this change included the revocation of a small number of domain validated SSL/TLS certificates previously issued for these domains.  Additionally, we have engaged with the registry that controls .PW to identify ways that can improve the safety of this top level domain for consumers.  Several other country-code and generic top level domains are also special targets for attackers, which we will continue to evaluate on an on-going basis as well.

        In contrast, forward looking, security minded registries, such as fTLD Registry Services, the owner of the .bank and .insurance top level domains are raising the bar for security for all of its customers. Considered a best practice, before authorizing a domain sale, these registries ensure that only valid, qualified entities operate on these domains and thereby protect the reputation of these spaces. As the original Certification Authority and the market leader for website security solutions, Symantec believes that verifying identity is critical for establishing trust and for ensuring the security of both consumers and the organizations they connect with online.

        Symantec works with the general public to help identify fraudulent websites.  If you would like to report SSL/TLS misuse, please log it here

        • domains
        • DigiCert Code Signing
        • certificate
        • Products
        • TLS
        • website security solutions
        • issue
        • Symantec Website Security
        • .pw
        • SSL
        • revoke
        • Products and Solutions
        • Security
      • Symantec CryptoExec for cPanel & WHMCS Makes SSL Administration Easy for Hosting Providers

        Aug 04 2015, 6:23 PM

        by Brook Chelmo 1

        Symantec would like to introduce the new CryptoExec for cPanel and WHMCS for hosting providers.  CryptoExec cPanel & WHMCS allows automating the SSL issuance process to mitigate errors and remove the manual steps in ordering and administration of SSL certificates for customers.  The intuitive and easy to use GUI helps customers buy and install SSL certificates.  Here is how it works:

        WHMCS Benefits

        The solution enables partners to utilize the popular WHMCS for billing/procurement of Symantec, GeoTrust, RapidSSL, and Thawte SSL and code-signing certificates and to provide a shopping cart experience.  The partner can also offer Trust Seals through WHMCS. 

        One other advantage of the solution is the flexibility offered for purchase through the support for either a voucher-based path or a classic SSL-based path. The voucher-based path is recommended for partners who have both cPanel and WHMCS so a customer can buy vouchers in WHMCS and redeem them in cPanel. The classic SSL path is recommended for partners who use WHMCS but not cPanel. 

        cPanel Benefits

        CryptoExec also enables cPanel, the popular control panel solution for hosting providers. Partners can utilize this solution to redeem vouchers purchased through WHMCS and automatically install all SSL certificate types without any manual intervention.

        Through cPanel, the Certificate Signing Request (CSR) generation is completely automated for partners who support both WHMCS and cPanel.  Additionally, the end customer will see live status messages on the progress of the certificate’s validation and installation.  cPanel will also provide a list of existing Symantec SSL certificates and the details related to each certificate. Through CryptoExec the complete lifecycle of an SSL certificate is covered; users can reissue, revoke and renew all SSL certificates through this solution. 

        CryptoExec cPanel and WHMCS modules also provide troubleshooting capability to hosting provider for the orders placed through WHMCS and cPanel.

        For WHMCS

        1. Download Symantec™ CryptoExec for WHMCS directly from Symantec’s Knowledge Base

        2. Add the module to your WHMCS installation

        3. In WHMCS, setup few initial product configurations and your customers are ready to start purchasing Symantec Products!

        For WHMCS and cPanel

        1. Download Symantec™ CryptoExec for WHMCS and Symantec™ CryptoExec for cPanel directly from Symantec’s Knowledge Base

        2. Add the module to your WHMCS and cPanel installations

        3. Within each system, setup your initial configurations and your customers are ready to start purchasing Symantec Products!

        • cPanel
        • SSL certificate
        • DigiCert Code Signing
        • Hosting
        • Products
        • TLS certificate
        • voucher
        • website security solutions
        • Symantec Website Security
        • CryptoExec
        • WHMCS
        • Products and Solutions
        • provider
      • New Rules: Feds Mandate HTTPS on U.S. Government Sites

        Jun 18 2015, 3:35 AM

        by Tiphany Zellers 1

        Have you read the news lately? It seems like hardly a week can go by without another data breach happening.

        In the past few years, cybercriminals have upped their game considerably, using incredibly sophisticated attacks in growing number. Out of every six large companies, five were targeted last year for attack—that’s a 40% increase over 2013.*

        The recent breach on federal employees’ private data, allegedly from China, only underscores the continued looming menace cybercriminals present—and this threat hasn’t gone unnoticed by the feds.

        In a January 12 post on the White House Blog, President Obama is quoted as saying: “This is a direct threat to the economic security of American families, and we've got to stop it.” Further adding, "If we're going to be connected, then we need to be protected."  So true! And that line of thinking is what prompted the U.S. government’s latest move.

        To help combat these attacks, the White House has mandated that all public-facing Web sites of the federal government must implement HTTPS within the next two years.

        This is no minor security update. It carries far-reaching implications that extend beyond the fed. Here’s what we mean.

        What HTTPS Offers to Everyone

        HTTPS provides a secure line of communication over the Internet, combining the usual HTTP (Hypertext Transfer Protocol) that you see in the address bar of unsecure sites, with SSL (Secure Sockets Layer) that you’re likely to see on most sites involving financial transactions.    

        This federal move shouldn’t come as a surprise, as the majority of the U.S. government sites have already made the switch to the secure protocol. This includes, which made the switch on March 11, 2015, to other federal sites that made the jump earlier, like,, and others.

        This goes beyond the initial site communication handshake—drilling down to subdomains, like, too.

        Up until now, many government sites are current with NIST-recommended SSL standards, but the administration has now moved to make prioritizing security and privacy a common practice among all aspects of federal government sites.

        Make no mistake about it, this is huge!

        These extra security measures follow the Always On SSL tenets advocated by the Online Trust Alliance, exhibiting some of the strongest moves yet to protect the identity and personal information of U.S. citizens online.

        Others Must Follow, Strengthening the Security of the Web

        Cybercrime isn’t going to easily back down.

        Now, it’s far too easy to compromise private information on sites with subpar security. Today’s cybercriminals are smart and tenacious. By protecting all aspects of a site with SSL—not just transaction pages—businesses can help quell social engineering techniques. These complex ruses can now fool even the savviest netizens into handing over their private information to the bad guys.   

        Nothing is 100% unhackable now and forever. But just like locking your car doors when you’re out, providing as much security as possible is still a good great idea! By expanding the coverage of SSL, we help further the strength and backbone of the Internet itself.

        *2015 Internet Security Threat Report, Volume 20


        • Products
        • website security solutions
        • DigiCert Code Signing
        • Products and Solutions
        • Symantec Website Security
      • Securing Telecommunications with Encryption

        Oct 20 2017, 8:46 PM

        by Terri Parker 2

        I know you have been waiting for this and it’s finally here!  May 17th is Voice Telecommunication day! One of the most common subjects raised, year after year, is how do we secure our telecommunication channels?

        In the past, where telephone calls were placed over a land line (PSTN), the only security issue was to worry about surveillance by the telephone company, and anyone who physically intercepted the line between you and the person you are talking to.

        While there are hardware devices and actual crypto-phones that can be used to safeguard your conversation, the devices come at a high price and with the move to mobile and internet communication, the effort & costs involved to install can be considered unnecessary.

        The advance in telecommunication networks and the Internet have made communicating easier and more cost effective, but unfortunately have also made the interception of calls more rampant than it has ever been. Without taking extra steps to protect your privacy, every phone call is vulnerable to eavesdroppers.

        If you're using a mobile phone, your conversation is conducted over a broadcast channel, which is easier to intercept than a physical line. There are numerous protocols involved in mobile technology with the most common being GSM.

        One thing that makes GSM special is its call encryption capability: it is designed to encrypt calls in between the handset and the local tower. Your GSM SIM card stores an encryption key, which is authenticated by your service provider (who has a copy of your key), at the nearest tower. The main problem with GSM is that the tower doesn't check back, which means that anyone can create a 'fake' tower and intercept your call.

        The GSM protocol dates back 30 years and the technology behind it, while still useful, is somewhat outdated. Fortunately Smart Phones support improved 3G or LTE standards, offering improved encryption and mutual authentication between your device and tower.

        If you're planning to deploy VoIP (Voice over Internet Protocol), or are already using it within your company, you firstly need to ensure that the data network you are using is secure. VoIP is vulnerable to all of the intrinsic security problems associated with IP and because VoIP transmits digitized voice as a stream of data, there is a risk of theft of private information by a hacker.

        There are many technologies, hardware and software involved in a VoIP system (depending on your requirements), such as

        • IP Phones- the end points that create and receive calls
        • Communication server/router – responsible for provisioning, monitoring & administering
        • Voice/Media Gateways  - contains protocols that interconnect your VoIP system and facilitate calls between IP and analogue

        Ensuring that they are secure is critical to keeping your network safe.

        VoIP uses the Session Initiation Protocol (SIP) and the Real-time Transport Protocol (RTP) for call signaling and voice-message delivery, these protocols do not encrypt the data

        Installing a Symantec SSL certificate on your VoIP server greatly enhances the security by encrypting the signals and securing the voice streams between your devices, preventing MITM (Man in the Middle) attacks and other compromises.

        Secure your communications with a Symantec Premium SSL certificates and implement an additional layer of protection with its free malware and vulnerability scanning services.

        Frequent scans of your server will help protect your networks from unwanted intrusions and help you proactively mitigate vulnerabilities.

        In addition to the Malware and Vulnerability services that Symantec Premium SSL certificates offer, it also includes a free an ECC (Elliptic Curve Cryptography) certificate alternative at no additional cost. ECC certificates provide stronger security and increased server performance due to the shorter key lengths (e.g. 256 bit ECC key provides the same level of security as 3,072 RSA key). It also reduces computational overhead on the server’s resources. Enjoy the flexibility of being able to use a single SSL certificate that can secure multiple domain names by simply adding them onto the same certificate. These types of certificates are known as SAN certificates or Unified Communications (UC) certificates and are commonly used with Microsoft server products (MS Exchange Server, MS Lync server etc.).

        Data Cables.jpg

        • Products
        • website security solutions
        • DigiCert Complete Website Security
        • Products and Solutions
        • Symantec Website Security
      • Vulnerabilities in Mobile Apps

        Mar 30 2018, 4:14 PM

        by Unknown 1

        Recently, we read about lots of SSL/TLS-related vulnerabilities found in mobile apps, which should come as no surprise. We were warned about this back in 2012 (see my previous blog). More warnings came in 2014 from CERT and FireEye. The Open Web Application Security Project (OWASP) listed “insufficient transport layer protection” as number three in its top 10 list of mobile security problems of 2014.

        One recent study found that thousands of mobile apps still used an old version of the OpenSSL library that was vulnerable to the FREAK attack. A similar problem was revealed by the creators of a popular mobile networking library called AFNetworking, when they disclosed a serious bug in their library that bypassed all SSL/TLS security checks. Although this bug and the one in OpenSSL were quickly corrected, thousands of mobile apps remain vulnerable until their developers recompile with the fixed version of AFNetworking or OpenSSL, and users upgrade to the fixed version of each app. Because these bugs were in application libraries and not in the operating system, phone vendors cannot automatically apply a patch. Given the slow rate at which users upgrade mobile apps, these vulnerable apps are likely to be with us for a long time.

        Failure to properly write and test SSL/TLS-related code might be due to ignorance or an assumption that the platform or library will “get it right”.  Sometimes SSL/TLS checks are disabled during development and debugging. App creators intend to re-enable the checks before the app is shipped, but they forget. That’s apparently what happened with Fandango and Credit Karma, who were cited last year by the FTC for SSL/TLS failures in their mobile apps.

        Developers don’t have to use blind faith; some good tools are now available for testing how an app works in the presence of a Man-in-the-Middle (MITM) like CERT’s Tapioca.

        In addition to the SSL/TLS certificate validation tests described in the white paper linked by my earlier blog, developers might also consider Public Key Pinning, defined in a relatively new RFC from the Web Security working group at the Internet Engineering Task Force (IETF). Developers need to apply caution, however, since one study pointed out the difficulty of building it correctly and the consequences of mistakes.

        • Products
        • website security solutions
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security
      • Could The Empire Have Been Saved by Better Encryption?

        Mar 29 2018, 10:20 PM

        by Jeff Barto 1

        I jumped at the opportunity to write this blog – as my son’s name is Luke and therefore, “Luke, I am your father”.

        Let’s remember that tense moment in Garbage Compactor 3263827:  after narrowly escaping Death-By-Dianoga, imminent demise again confronts Leia, Luke, Chewbacca and Han as the garbage compactor starts doing what garbage compactors do best.  The young rebels frantically call C3PO and R2D2 to shut down all the compactors on the detention level – and in those gripping minutes leading to their narrow escape, even the most hyperaware geeks all totally missed evidence that the Imperial IT/IS department made some pretty bad decisions about SSL certificates. 


        For two decades, SSL has been the guardian of encryption and validation on a very public internet, but also within enterprises – even evil enterprises like the Death Star.  And while the chronology means that SSL couldn’t have been in use a long time ago, in a galaxy far, far away, luckily the timing is fiction while SSL best practice is fact. 

        This little lesson’s worth the effort.  Come, let me get you some SSL context: 

        To save his colleagues in the compactor, R2D2 got access to a Death Star control system.  The Death Star’s systems believed that R2D2 was a legitimate agent of the Empire, and allowed him access.  Now, let’s presume that the data exchange which ensued between system access and compactor shutdown was over an encrypted channel (a classic implementation of encryption of data in motion in a server-to-server model).  Encryption wouldn’t have prevented R2D2 from doing anything – since he already had access to the network.

        Had the Death Star’s systems required a digital certificate – what we now call SSL or TLS – for validation, not just encryption, the result might have been very different for not just our rebel friends, but ultimately for the Rebel Alliance and the Empire too – and for millions of Star Wars fans, in any galaxy for that matter. 

        After all, losing track of Death Star plans isn’t Imperial IT’s only problem.  They also failed to observe best practices for usage of specific certificate types within their space station, as encryption couldn’t have prevented R2D2’s access.  Only the validation function of SSL could have resolved that. 

        Stick with me here.  Use the Force.  Trust your feelings.  Let go.

        Effectively, R2D2 was a man-in-the-middle.  Er, droid-in-the-middle.  But don’t let “MITM or DITM” distract.  If the Death Star’s server-to-server authentication demanded domain-validated certificates, the clever R2D2 could have easily obtained one of those since he literally was a man-in-the-middle.  (Think about all the various DV authentication methods – R2 could’ve faked any of them).  And upon system access, R2 just presented his DV certificate upon connecting the Death Star network and – ta da, he’s avoided any Imperial entanglements.  (As I’m writing this, I realize that the Empire would likely have obtained the very first ever TLD, presumably for .ge for galactic empire – making R2’s DV cert’s Common Name to be something like

        Now, if Death Star IT/IS had configured its systems to demand organization-validated (OV) or Extended Validation (EV) certificates for server-to-server communication, R2 would have either failed to connect (by having a DV cert) or failed OV/EV verification (since he couldn’t have proven that he’s a member of the Empire). 

        No OV/EV = no (suitable) cert presented = this isn’t the droid you’re looking for = dead rebels.

        Moreover, Imperial IT/IS would’ve been even smarter if they’d have selected any of Symantec-branded SSL certificates, which only come in OV and EV flavors – as the Symantec SSL validation and issuance infrastructures have never been compromised – since clearly the Death Star has its own breach problems.

        Moral of the story:   demand Symantec OV or EV certificates, even for server-to-server usage.  And may the Force be with you.

        • Products
        • website security solutions
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security
      • Mitä kuluttajan tulisi tietää SSL-varmenteista

        Mar 29 2018, 8:40 PM

        by Jeff Barto 0

        eBusiness Green Bar 400x210.jpg

        1994 tehtiin ensimmäinen verkko-ostos: iso pepperonipizza herkkusienillä ja extrajuustolla, Pizza Hutista. Seuraavien 20 vuoden aikana verkkokauppatalous on ollut vilkasta ja 2013 myynti ylitti 1,2 biljoonaa Yhdysvaltain dollaria.

        Verkkokaupankäynnin kasvu perustuu luottamukseen. Kuluttajat luottavat sivustojen pitävän kirjaa rahavirrasta, ja että ostosten tekeminen on turvallista ja laillista suurimmaksi osaksi Secure Socket Layer (SSL) –varmenteiden ansiosta, joka tunnetaan myös pienenä vihreänä lukkona osoitekentässä.

        SSL-varmenteet varmistavat, että toimittaja on se, kenen he väittävät olevansa. Se osoittaa myös, että yhteys kuluttajan laitteiden ja yrityksen verkkosivujen välillä on turvallinen. SSL-varmenteiden toiminnallisuuden ymmärtäminen on tärkeää välttääkseen huijarien ansaan joutumisen. Sillä loppupeleissä kaikki sivustot – tai SSL-varmenteet – eivät ole luotu tasavertaisiksi.

        Erilaiset varmennetyypit

        Verkkosivustojen omistajat ostavat SSL-varmenteet varmentajalta (Certification Authority, CA). On olemassa kolmen tyyppisiä SSL-varmenteita, joista jokainen tarjoaa eri tasoisen suojan. Ongelma piilee siinä, että vaikka kaikki varmenteet tarjoavat selaimen osoitekenttään tutun turvalukon yhdessä HTTPS-yhteyden (”S” viittaa englannin turvattu-sanaan, ”secure”) kanssa, turvatasot vaihtelevat suurestikin. Tämän vuoksi on tärkeää ymmärtää millaista SSL-varmennetta sivusto käyttää ennen, rahallisen liiketoimen harjoittamista tai ylipäätään mitään, johon liittyy henkilökotaiset käyttäjätiedot.

        • Domain validated eli domainvarmennettu (DV):  Tämä vahvistaa sivuston omistajan. Prosessi on yksinkertainen, jossa varmentaja eli CA toimittaa sähköpostin siihen sähköpostiosoitteeseen, jolla sivusto on rekisteröity identiteetin vahvistaakseen. Yrityksestä itsestään ei vaadita tietoja. Verkkorikolliset käyttävät yleensä DV-varmenteita, koska ne on helppo hankkia ja sen avulla sivustosta saa turvallisemman kuvitelman kuin onkaan.  Huijarit saattavat käyttää DV-varmenteita houkutelleksaan kuluttajia tietojenkalastelusivustoille, jotka näyttävät aidoilta tai kopioidakseen jonkun sivuston näyttämään tunnetulta sivustolta, mutta jonka tarkoitus on varastaa henkilökohtaisia tietoja.
        • Organizationally validated eli yritysvarmennettu (OV): Saadakseen OV-varmenteen varmentajan on varmennettava tiettyjä tietoja, kuten yrityksen olemassaolon yritysrekisteristä, sen fyysisen sijainnin ja verkkosivuston omistajan. Prosessi kestää yleensä muutaman päivän.
        • Extended validation (EV): Tällä varmenteella on korkein suojaustaso ja se on helpoiten havaittavissa. Myöntääkseen EV-varmenteen varmentaja suorittaa hakijasta tehostetun tarkistusprosessin kasvattaakseen yrityksen luottamusta. Tarkistusprosessissa käydään läpi yrityksen asiakirjat, varmennetta hakevan henkilön identiteetin tarkistus ja tietojen tarkistus kolmannen osapuolen tietokannasta. Turvalukon ja HTTPS:n lisäksi EV-varmenteella suojattu sivusto muuttaa osoitekentässä olevan yrityksen nimen vihreäksi.

        Huomaatko eron?


        Viimeisin osoite on selvästi suojattu EV-varmenteella. Ensimmäinen on DV-varmenne ja keskimmäinen OV-varmenne, jotka näyttävät verrattaessa identtisiltä.

        Mitä voi tehdä pysyäkseen turvassa?

        Nyt kun tiedetään mikä SSL-varmenne on ja sen kolme eri tyyppiä, ja että DV-varmenteella suojattu sivusto on huijatuksi tulemisen riskialueella, kuinka käyttäjät voivat pienentää riskiä shoppaillessaan ja naputellessaan muuta kriittistä tietoa verkossa?

        1. Ole varuillasi! Vaikka sivustolla olisi turvalukko tai osoiterivin alussa “https” ei tee sivustoa turvalliseksi rahaliikenteelle. Käyttäjät ovat oppineet etsimään näitä kahta ennen tapahtuman läpiviemistä ja juuri tästä syystä verkkorikolliset näkevät vaivan hankkia SSL-varmenteen – näyttääkseen aidolta sivustolta.
        2. Opettele erottamaan, mitä varmennetyyppiä sivusto käyttää. Etsi ensimmäiseksi visuaalisia vihjeitä, kuten lukkosymbolia ja osoitekentän vihreää väriä. Ainoastaan EV-varmennetut sivustot ilmoittavat yrityksen nimen osoitekentässä. Selaimet eivät osaa erottaa DV-varmennetta OV-varmenteesta. Norton on luonut ilmaisen työkalun ( varmenteiden erottamiseksi. Kopioi verkkosivun osoite suoraan työkalun kenttään ja se kertoo, mitä varmennetyyppiä sivusto käyttää ja kuinka turvallinen sivusto on kyseessä.
        3. Asioi ainoastaan OV- ja EV-varmenteilla suojatuilla sivustoilla. DV-varmenteille on aikansa ja paikkansa, mutta niitä ei tulisi käyttää kaupallisilla sivustoilla. Jos käyt testaamassa osoitteen Nortonin työkalulla (( ja tuloksena on DV-varmenne, mieti kahdesti ennen kuin asioit pidemmälle kyseisellä sivulla. Jos kyseessä on OV- tai EV-varmennettu sivusto tiedät, että yrityksen tiedot ovat tarkistettu.

        Verkkoshoppailu ei ole katoamassa mihinkään. Niin kauan kun ala ei vaadi OV- ja EV-varmenteiden käyttöä kuluttajien on kannettava kortensa kekoon riskien minimoimiseksi verkossa.  Kun riskit on tiedossa, kuluttajat jäävät mitä pienemmällä todennäköisyydellä tietojenkalastelijoiden ansaan.

        Lisätietoja SSL-varmenteista löytyy hiljattain julkaistusta Symantec whitepaperista ( tai vierailemalla Trust Services ( –sivustollamme.

        Alkuperäinen teksti:

        • Products
        • website security solutions
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security
      • How the Private and Public Key Pair Works

        Oct 20 2017, 8:30 PM

        by Charlotte Pommier 0

        Did you know this month was “couple appreciation month”? Let’s use this as an opportunity to explain in simple words how the security of an online transaction relies on a happy, inseparable couple: a public key and a private key.

        Public keys and private keys are part of a general structure we call PKI – Public Key Infrastructure. The SSL and TLS protocols, which are globally used to secure not only websites, but also emails and web applications, are based on this structure. So we might as well say that there are thousands and thousands of public and private keys in operation right now around the world!

        Keys are used in algorithms to encrypt and decrypt data. You may think the same key is used to encrypt and decrypt, but there’s a twist: there are algorithms in this world which are able to encrypt data with one key… and decrypt it only with the help of another key! Magical, isn’t it? (For those who don’t believe in magic, you can read more about trapdoor functions here). In the case of SSL, one key – the public key - is used to encrypt data; only the corresponding private key can decrypt it. What a lovely (and useful) couple.


        In the SSL protocol, public keys and private keys are generated by servers. The private key remains locked and secure in the server, while the public key is pinned to the server’s SSL certificate. Whenever a browser connects to the server, the server sends its SSL certificate which contains the public key. The browser can then use this public key to encrypt data and send it to the server, which is now the only one able to decrypt such data thanks to its private key.

        Both keys are inseparable, and of course each pair is unique: the public key belongs to its corresponding private key and only to this one.


        Public and private keys are essential to the security of our exchanges. Thanks to them, we don’t have to worry about someone eavesdropping on our conversations. But there is still a major issue: what if a hacker intercepts the server’s public key, and sends their own public key instead?

        What guarantees the browser that the public key received is actually the public key from the server it wanted to reach?  This is why Certification Authorities like Symantec play an essential role: CAs authenticate servers and their public key through a unique document called the SSL certificate!

        If you’re curious about SSL and more specifically about how SSL certificates work, you can find more

        • Products
        • website security solutions
        • DigiCert Complete Website Security
        • Products and Solutions
        • Symantec Website Security
      4 pages