Announcements & Articles : All Posts
  • April 18, 2017

    The Certificate Authority Browser Forum, Also known as CA/Browser Forum, is a voluntary consortium of Certificate Authorities such as Symantec, Digicert, Comodo, and tech Operating System makers such as Apple, Mozilla, Microsoft, etc.. decide the fate of security on the internet. The CA/Browser Forum purpose is to be proactive, and keep the internet secure for users and businesses all over the world.

    The CA/Browser Forum recently passed Ballot 193 will effect all Certificate Authorities and those who manage SSL/ TLS Certificates. Effective almost immediately (April 22, 2017).

    • Effective April 22, 2017
      Reduces the length of time that authenticate information can be re-used to authenticate subsequent certificate, from 39 months (3 years 2 months) to 27 months (825 days / 2 years) New, Renewal and Replacement certificates will be subject to this change. This seems a little abrupt and might be changed in order for the CA’s to prepare for this new standard but should not effect the majority of clients while this transition is taking place.
    • Effective March 1, 2018
      Decreases the maximum validity period of SSL/TLS Certificate to 27 months (825 days). Eventually there will be no more three year option. No certificate after this date can have a validity passed 27 months.

    Things to know:

    Authentication:

    • Existing certificates:
      • Are not effected. The authentication work is already complete and no action is necessary.
    • Reissue (replacement) of your SSL Certificate:
      • DV (Domain Validated Certificates) –
        DV certificate reissues such a Quick SSL or Rapid SSL Products currently undergo domain validation; this there is no impact to DV certificate reissues. Reissued 3rd certificates after March 1 2018
      • OV (Organization Validation) –
        Some OV reissues for products like True ID or Secure Site may not instantly issue in the event that the authenticated data used to approve the original certificate is older than 825 days or is otherwise no longer valid. In some cases, reissues will undergo authentication, though many reissue will continue to be instantly issued. Typically 3 year certificate may be effected by this revalidation and not get automatically reissued.
      • EV (Extended Validation) –
        EV reissues are not impacted due to their already 2 year 825 validity day nature.
    • Renewal certificates:
      • Certificate renewal will continue to leverage existing authentication and automation whenever possible, and in many cases will be quickly approved.
      • With the shorter validity of authentication data (27 months), renewals will require more frequent authentications.
      • With the shorter validity period network admins will have visit their server & networks more frequently for CSR generation and SSL installation.

    Technical:

    • Reissues/Replacements:
      • Since the technical validity of a certificate after the date of March 1, 2018 can only have a 27 month / 825 day lifespan if for whatever reason a reissue is needed the certificate may have time removed from their certificate.
        Example: If an Admin gets a new/renewed 3 year certificate on February 29th 2018 and needs to perform a reissue due to a technical matter we could see a certificate cut to 27 months instead of 37 months.
        Note: Due to this technicality Acmetek will be proactive and will put a stop to 3 year certificate enrollments to closer the deadline approaches to prevent this scenario the best we can.

    To keep up with the progress of technology the CA/Browser Forum is always coming up with new industry standards. These standards guide and move the internet to a more safer and secure environment for its users. Information regarding the CA/B Forum on is always made publically available at cabforum.org


    Lead Tech Engineer, Acmetek
    Dominic Rafael

  • March 24, 2017

    Firstly, key note is that Certificates today require no action – there is no security issue nor any issues with issuance !! Google’s unilateral changes to the Chrome browser do not require any action immediately. Enough is Enough.

    On behalf of Symantec, we want you to note that Symantec is proud to be one of the world’s leading certificate authorities. Symantec strongly objects to the action Google has taken to target Symantec SSL/TLS certificates in the Chrome browser. This action was certainly unexpected, and Symantec believes the blog post was irresponsible! Symantec hopes that this was not calculated to create uncertainty and doubt within the Internet community about our SSL/TLS certificates.

    Google’s statements about Symantec’s  issuance practices and the scope of Symantec’s  past mis-issuances is exaggerated and misleading. For example..

    • Google’s claim that Symantec has mis-issued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates – not 30,000 – were identified as mis-issued, and they resulted in no consumer harm as they were for test purposes .
    • While all major CAs have experienced SSL/TLS certificate mis-issuance events, Google of recent has singled out the Symantec Certificate Authority in its proposal even though the mis-issuance event identified in Google’s blog post involved several CAs.

    Symantec has taken extensive remediation measures to correct this situation, immediately terminated the involved partner’s appointment as a registration authority (RA), and in a move to strengthen the trust of Symantec-issued SSL/TLS certificates, announced the discontinuation of our RA program. This control enhancement is an important move that other public certificate authorities (CAs) have not yet followed.

    Symantec operates our CA in accordance with industry standards and maintains extensive controls over our SSL/TLS certificate issuance processes and Symantec works to continually strengthen their CA practices. Symantec has substantially invested in, and remain committed to, the security of the Internet.  Symantec has publicly and strongly committed to Certificate Transparency (CT) logging for Symantec certificates and is one of the few CAs that hosts its own CT servers.  Symantec has also been a champion of Certification Authority Authorization (CAA), and has asked the CA/Browser Forum for a rule change to require that all certificate authorities explicitly support CAA. Symantec’s most recent contribution to the CA ecosystem includes the creation of Encryption Everywhere, our freemium program, to create widespread adoption of encrypted websites.

    Note that Symantec wants to reassure their customers and all consumers that they can continue to trust Symantec SSL/TLS certificates.

    Symantec will continue to vigorously defend the safe and productive use of the Internet, including minimizing any potential disruption caused by the proposal in Google’s blog post. Symantec is currently open to discussing the matter with Google in an effort to resolve the situation in the shared interests of our joint customers and partners.

    “We suggest and strongly recommend that you continue as normal with your procurement of Symantec SSL Certificates as we are working to clarify Google’s statement. You can expect an update soon once we assess if changes are necessary.”

    –  Lead Engineer – Encryption , Acmetek Global Solutions, Kevin S Naidoo

  • February 22, 2017

    We want to inform you about new industry requirements that were announced by the Certificate Authority Security Council (CASC) for Code Signing certificates on 8th December 2016 and that comes into effect on the 1st of February 2017.

    The new requirements address four key areas within our Code Signing products and provide a safer experience and minimize the risk of Code Signing attacks.

    To reduce the chance of issuing certificates to malicious publishers the guidelines require that Symantec:

    • Follow a strict and standardized identity verification process to authenticate publishers
    • Check all Code Signing orders against lists of suspected or known malware publishers
    • Check all Code Signing orders that were previously revoked by Symantec where the certificates were used to sign suspect code.Code Signing Important

    Symantec has also introduced a ‘Certificate Problem Reporting’ system for both Symantec and Thawte Code Signing certificates which will allow third parties like malware organisations and software suppliers to report issues relating to key compromise, certificate misuse and possible fraud. Under the new arrangement, once Symantec receives a request, we will either revoke the certificate within forty eight hours, or alert the requestor that we have started an investigation.

    Symantec has enhanced their timestamping services for their Code Signing customers to meet the new requirements. More information can be found in the following KB articles for Microsoft Signing and Java Signing.

    The main benefit of using a timestamp is that the signature does not expire when the certificate does, which is what happens in normal circumstances. Instead, the signature remains valid for the lifetime of the timestamp, which can be as long as 135 months.

    Symantec has published a set of guidelines on private key protection best practices for Symantec and Thawte Code Signing certificates which must be reviewed and accepted by subscribers as part of the enrollment process. These guidelines makes recommendations regarding the secure storage of private keys to mitigate against the risk of potential vulnerabilities, however it is important to call out that Code Signing minimum requirements published in December stop short of mandating that an OV Code Signing certificate must be stored on a FIPS 140-2 Level 2 HSM or equivalent on premise hardware.

    Lastly, any pending Symantec or Thawte Code Signing orders placed before the 25th of January 2017 and not issued before the 1st of February 2017 will be cancelled by Symantec and respective customers asked to re-enroll.

    If you want any further clarification about this announcement, or have any questions feel free to get in touch your Certificate Authority who issued your Code Signing Certificate.


    Dominic Rafael, Lead Tech Engineer
    dsrafael@acmetek.com

  • February 14, 2017

    WhatsApp Enables Two Factor Authentication Strengthening it’s Security.

    WhatsApp is a widely popular free to use cross platform smart phone messaging application that allows users to use their phone service and wifi internet to make voice/video calls, send text messages, documents, images, gif’s, user locations, etc. Its popularity is primarily due to where data rates or roaming charges can cost an arm and a leg.

    WhatsApp Inc., based in Mountain View, California, was acquired by Facebook in February 2014 for ridiculous $19.3 billion US Dollars. By February 2016, WhatsApp has a user base of over one billion, making it the most popular messaging application at the time.

    Over the recent years Privacy and Security has been a focus on the popular message app. In 2014 WhatsApp implemented end to end https encryption scrambling the information between communicating users. The latest Security implementation is the coming of Two-Step Verification.

    What is Two-Step Verification?

    Two-step verification is an optional feature that adds more security to your account. The technology is not new, and it has been in use for quite some time. Blizzard Inc. creator of the biggest online MMO (Massive Multiplayer Online) game World Of Warcraft implemented two factor authentication back in 2008 to protect gamers accounts from being hacked. Two-step, or Two-Factor Authentication protects your accounts by requiring you to provide an additional piece of information after you give your password In the most common implementation, after correctly entering your password, an online service will send you a text message or an email with a unique string of numbers that you’ll need to punch in to get access to your account.

    Implementing Two Step Verification on WhatsApp:

    To enable two-step verification, open WhatsApp > Settings > Account > Two-step verification > Enable.

    Upon enabling this feature, you can also optionally enter your email address. This email address will allow WhatsApp to send you a link via email to disable two-step verification in case you ever forget your six-digit passcode, and also to help safeguard your account. WhatsApp will not verify this email address to confirm its accuracy. You will want to provide an accurate  email address so that you’re not locked out of your account if you forget your passcode.

    How it works..

    After implementing Two-Step Verification if you receive an email to disable two-step verification, or receive a pass-code request but did not request this, do not click on the link! Someone could be attempting to verify your phone number on WhatsApp elsewhere. Meaning that someone is attempting to gain access to your account! Stay secure.


    Lead Tech Engineer: Dominique Rafael
    dsrafael@acmetek.com