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

 

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.

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

The term SSL certificate has been used for the purposes of marketing since the creation of the digital certificates. SSL just like TLS are actually protocols that utilize a digital certificates keypair.

A digital certificate keypair by itself is nothing more than a place holder of 2048 bits or greater and is needed in order to perform encryption and validation. A protocol is the actual function of encryption that initializes that keypair to start encryption, such as the TLS or SSL Protocols. These protocols are set up and chosen on the server side by a server admin. Since TLS or SSL are protocol functions on the server and not pertaining to the digital certificate’s keypair it is uncertain why the industry calls Digital Certificates as SSL Certificates because of this principle. All SSL protocols that were all available are now perceived as a vulnerable protocol leaving only TLS until something better eventually comes up.

Because of the SSL marketing gimmick around the industry, and lack of secure SSL protocols there is now a fountain of confusions flying around. Here are some examples:

“Since SSL Versions are vulnerable to Poodle attack. Is it possible to consider TLS 1.2 instead of SSL certificate?”

“We need to upgrade our SSL certificate to TLS 1.2”

“My certificate states its is a SSL certificate, but I asked for a TLS certificate did I do something wrong?”

A standard digital certificate can use both TLS and SSL because they are both protocols that are configured on the server. There is no such thing as an SSL certificate that will only work for the SSL protocol or a TLS certificate that will only work for the TLS protocol.

Remember, that a digital certificate keypair is essentially just a bit place holder for encryption. All mainstream digital certificates are essentially TLS/SSL because of the protocols that can use it.

---

About SSLSupportDesk:

SSLSupportDesk is part of Acmetek who is a Symantec Website Security Solutions Authorized Distributor and a Platinum Partner. Acmetek offers all 4 Brands of SSL Certificates: Symantec, Thawte, GeoTrust and RapidSSL. Offering Norton Shopping Guarantee that inspires trust and increases online sales with a 20x ROI Guarantee.

Contact an SSL Specialist to buy your SSL Certificates from Acmetek, a Symantec Strategic/Platinum Distributor.

Become a Partner and create additional revenue stream while the heavy lifting for you.

Enrollment for Microsoft Authenticode/Office-VBA Code Signing is a fairly simple process unlike Java Code signing. But there are some steps that need to be explained and remembered in order to have a successful enrollment, and certificate pickup.

Microsoft Authenticode/Office-VBA Code Signing is used to Digitally sign 32-bit or 64-bit user-mode (.exe, .cab, .dll, .ocx, .msi, .xpi, and .xap files) and windows kernel-mode software. As well as digitally sign Microsoft Office VBA objects, macros, and third-party applications using VBA.

Here is a list of things to be aware of when enrolling for Microsoft Authenticode/Office-VBA Code Signing:

1. Certificate creation for Microsoft Authenticode/Office-VBA Code Signing is conducted in your browser during enrollment. Depending  on the code signing product you will be advised on the enrollment requires, such as what browser to use.
   Note: When enrolling for a code signing certificate through Acmetek or SSL2048 it is required to use a Firefox or Internet Explorer Browser for enrollment and pickup of the code signing certificate.
2. The legal information added to the code signing certificate is pulled directly from the information you enter during enrollment.
3. If you would like your code signing certificate to look a certain way you must specify it as such in all the required fields pertaining to Corporate Legal Name or Company fields.
   Example:
   acmetek global solutions inc will not give me the more visually appealing Acmetek Global Solutions, Inc. The enroller must state Acmetek Global Solutions, Inc. in order to get it on the issued certificate.
4. If you have a subdivision that is responsible for this code signing certificate you will have the option to specify it under the Division or OU fields during enrollment.
5. Important: During enrollment you will have the option to list the Technical Contact on the order. The enroller is actually creating the private key pair within their browser. It is important to keep this in mind for the following reasons…
   • Once the certificate gets issued a email will be sent to the Technical Contact with instructions to click on a link in order to pick up their Microsoft code signing product. That link must be Clicked-on/Copy-Pasted into the same System/Browser that was used for the initial enrollment of the code signing certificate.
   • If the enroller – Admin Contact is different than the Technical Contact that email  must be forwarded to the enroller in order to Clicked-on/Copy-Paste the link  into the same System/Browser that was used for the initial enrollment of the code signing certificate.
6. The certificate pickup link must be Click-on/Copy-Paste the link  into the same System/Browser that was used for the initial enrollment of the code signing certificate.
7. Once you get confirmation in your browser that the code signing certificate has been installed you can begin your signing or export/backup the code signing certificate and distribute it to your developers.
8. For instructions on how to export/backup your code signing certificate click on one of the links below for the corresponding browser you used.
   How to export a certificate from Firefox
   How to export a certificate from Internet Explorer

With your new Microsoft Code Signing certificate you will sign your windows based applications. For actual signing procedures, support and more information on how to code contact Microsoft.

---

About SSLSupportDesk:

SSLSupportDesk is part of Acmetek who is a trusted advisor of security solutions and services. They provide comprehensive security solutions that include Encryption & Authentication (SSL), Endpoint Protection, Multi-factor Authentication, PKI/Digital Signing Certificates, DDOS, WAF and Malware Removal. If you are looking for security look no further. Acmetek has it all covered!

Contact an SSL Specialist to get a consultation on the Website Security Solutions that can fit your needs.

Become a Partner and create additional revenue stream while the heavy lifting for you.

Getting a Java Code Signing is more of a manual process compared to Micrsosoft Authenticode/Office-VBA Code Signing.

Java Code Signing is used for signing Java applications for desktops, digitally sign .jar files and Netscape Object Signing. Recognized by Java Runtime Environment (JRE).

The following instructions are a supplemental guide into generating and configuring a keystore necessary for Java Code Signing. If you have not already done so, you will need to download the Java Software Development Kit (SDK) from Oracle. If you have any questions or assistance in implementing the Java SDK for best support contact Oracle.

Unlike other types of code signing in order to get a Java Code Singing Certificate you will need to use the keytool utility to create and configure a keystore .jks. Keep your keystore safe and make backup copies. If you lose your keystore file, or your password to access it you will need start from scratch by generating a new keystore and perform a replace the certificate.

This article will go over the following:

1. Step 1 – Create a Keystore
2. Step 2 – Generating a CSR needed for enrollment for your Java Certificate.
3. Steps 3 & 4 – Installing the Java Certificate after its issuance.

In order to create and configure your Keystore for Java Code Signing perform the following.

Step 1: Create a Keystore:

1. Create a certificate keystore and private key by executing the following command:
   Note: You will specify a Privatkey Alias. This Alias will be used for CSR creation and eventually installation of the Java Code Signing Certificate.

   keytool -genkey -alias create_Privatkey_Alias -keyalg RSA -keystore path_and_create_KeystoreFilename.jks -keysize 2048

2. Example:
3. Enter and re-enter a keystore password.
   Note: Remember your Alias Name and your password for your private key. You will require it for installation!
4. Fill out the applicable information:
   
   • First and Last Name? or Common Name (CN): With java code signing the common name of the certificate is is your Organization Name .Example: XY & Z Corporation would be XYZ Corporation
   • Organizational Unit (OU): This field is optional; but can be used to help identify certificates registered to an organization. The Organizational Unit (OU) field is the name of the department or organization unit making the request.
   • Organization (O): If your company or department has an &, @, or any other symbol using the shift key in its name, you must spell out the symbol or omit it to enroll. Example: XY & Z Corporation would be XYZ Corporation
   • Locality or City (L): The Locality field is the city or town name, for example: Boston
   • State or Province (S): Spell out the state completely; do not abbreviate the state or province name, for example: New York
   • Country Name (C): Use the two-letter code without punctuation for country, for example: US or CA.
     
     
     
5. Confirm or reject the details by typing “Yes” or “No” and press Enter.

Step 2: Creating your CSR from your keystore:
Now that your keystore has been created you can now generate your CSR from it.

1. Use the following command to create your CSR from your Keystore.

   keytool -certreq -keyalg RSA -alias your_privatekey_alias -file your_csr_file.csr -keystore your_keystore_filename.jks

2. Create a copy of the keystore file. Having a back-up file of the keystore at this point can help resolve installation issues that can occur when importing the certificate into the original keystore file.
3. To copy and paste the file certreq.csr into the enrollment form, open the file in a text editor that does not add extra characters (Notepad or Vi are recommended).

Your CSR request for your Java Code Signing Certificate has been created and is ready for you to copy and paste its contents into the enrollment portal when enrolling for a Java Code Signing certificate.

Step 3: Picking up your Java Certificate:

1. After validation the Java Certificate will be sent to the Technical Contact via email. You will see your Java certificate in the body of that email.
2. Copy the Java Certificate and make sure to copy the —–BEGIN PKCS7 CERTIFICATE—– and —–END PKCS7 CERTIFICATE—– header and footer. Ensure there are no white spaces, extra line breaks or additional characters.
3. Use a plain text editor such as Notepad, paste the content of the certificate and save it with extension .p7b (When performing this on a Windows system the Icon of the file should change into a certificate icon)

Step 4: Installing your SSL certificate:
It is recommended that you have your Keystore, SSL certificate and Keytool.exe in the same folder or you will need to specify the full file path when running the following commands. you may want to make a copy of your Keystore in case their are issues with Installation.

1. Import the SSL certificate into the keystore used for CSR creation.
   Note: Use the same Privatekey alias name based on when you created the keystore for CSR creation.
   

   keytool -import -alias your_Privatekey_alias -trustcacerts -file your_SSL_Certificate.p7b  -keystore your_keystorename.jks

2. You will be prompted to enter the password to access the keystore.Note: If you do not know your password you will have to start from scratch by generating a new keystore, a new csr, and perform a reissue of the certificate.

If the installation is successful you will see “Certificate reply was installed in keystore”.

Your Java Certificate should now be installed and configured into its keystore. With this configured keystore you will Sign your Java Code.

For actual signing procedures and information on how to code view Oracles Tech notes using Jarsigner.

If you are unable to use these instructions, Acmetek recommends that you contact either the vendor of your software or the organization that supports it.

Oracle Java Support

For more information refer to Java.

---

About SSLSupportDesk:

SSLSupportDesk is part of Acmetek who is a trusted advisor of security solutions and services. They provide comprehensive security solutions that include Encryption & Authentication (SSL), Endpoint Protection, Multi-factor Authentication, PKI/Digital Signing Certificates, DDOS, WAF and Malware Removal. If you are looking for security look no further. Acmetek has it all covered!

Contact an SSL Specialist to get a consultation on the Website Security Solutions that can fit your needs.

Become a Partner and create additional revenue stream while the heavy lifting for you.

There are many SSL checkers out there which are used to check the validity and installation of a websites SSL Certificate. Majority of these checkers may vary on the information that they display or may have limitations, as they only perform their function as programmed. Aside from using an SSL Checker tool there is always the manual way of using your browser to check proper installations.

If you would like to learn how to check using a browser SSLSupportDesk features such an article Troubleshooting: Checking SSL installation with a browser.

Some SSL Checkers are extremely advanced and will not only check the validity of a SSL certificate, but can also point out flaws in a server’s configuration or software.

Qualys SSL Labs has an SSL Server Test (SSL Checker) tool that is well executed and implemented.

Please follow these steps to test your installation:

1. Access the Qualys SSL Labs Server Test checker, click here
2. Enter the URL/Domain name of the server that you wish to check & click Submit

---

---

Troubleshooting Unresolved https address:

SSL checkers will only work if your website is publicly accessible from outside your network. More than likely if your website is internal you will not get any results.

Example: We used a domain name that does not exist in the outside work and get this result.

---

How to read Qualys SSL Server Test Checker:

Using sslsupportdesk.com which is accessible to the open internet lets see how Qualys SSL Server Test Checker works.

With a successful installation we should see the following quality of the server system:

Summary:

1. Overall Rating: Based on the quality of the server system running the Domain Name submitted. Factors that attribute to this Overall Rating are from combining the categories of Certificate, Protocol Support, Key Exchange, Cipher Strength.
2. Certificate: Factors to this Quality are…
   1. Domain name mismatch.
   2. Certificate not yet valid.
   3. Certificate expired.
   4. Use of a self-signed certificate.
   5. Use of a certificate that is not trusted.
   6. Use of a revoked certificate.
3. Protocol Support: The encryption protocols that are available to clients visiting this web server.
4. Key Exchange: The distribution of the public and private keys and their strength when setting up encryption between client and server.
5. Cipher Strength: Ciphers perform the actual encryption/decryption of the key pair running on the server system. Some can be considered weak, others strong.

Troubleshooting:

If there are any warnings or concerns the Qualys SSL Server Test Checker finds will be denoted below the Summary.

Red = Very bad
Yellow = Advisories or Industry changes that may turn into red over time.

More information regarding the checkers findings can usually be found by clicking MORE INFO.

Note: You may need to contact your server hosting provider or server vendor in order to perform updates, how to turn off certain protocols, or set the proper configurations needed for a good rating.

---

Authentication:

Server Key and Certificate # 1: States the information pertaining to the SSL certificate running on the Server System in Https:
Additional Certificates (If Supplied): Lists any additional Certificates that are also radiating off the server system. Usually these are Intermediate CA certificates.
Certification Paths: Shows the entire Chain Of Trust. Usually SSL Certificate > Intermediate > Root.

Note: The last certificate in this chain will be the root certificate. At times a yellow “Sent by Server” may appear on the Root. This only means that when a SSL connection is being made to the server that the server is presenting and forcing a root certificate to the client. Usually the Root certificate should only rest in the client’s browser Trust Store. Don’t be alarmed as some servers have to present this due to their programming. Although proper practice dictates that they shouldn’t.

---

Configuration:

Protocols: The encryption protocols that are available to clients visiting this web server.
Cipher Suites: The child protocols the perform the actual encryption session.
Handshake Simulation: Mimics the different browsers used to connect to the server.
Off Note: Most modern browser systems will automatically choose the best most secure connection the browser is capable of regardless of how the server is configured.
Protocol Details: More information regarding how the server system is handling protocols.
Miscellaneous: Server type running Domain Name, Timestamp check occurred, etc.

---

Qualys SSL Labs Server Test Checker tool is operated and managed by Qualys. This SSL Checker is one of many publicly available on the internet that can help you diagnose problems with your SSL certificate installation, or other errors that are associated with your server system.

Note: You may need to contact your server hosting provider or server vendor in order to perform updates, how to turn off certain protocols, or set the proper configurations needed for a good rating.

---

About SSLSupportDesk:

SSLSupportDesk is part of Acmetek who is a Symantec Website Security Solutions Authorized Distributor and a Platinum Partner. Acmetek offers all 4 Brands of SSL Certificates, Symantec, Thawte, GeoTrust and RapidSSL.Offering Norton Shopping Guarantee that inspires trust and increases online sales with a 20x ROI Guarantee.

Contact an SSL Specialist to buy your SSL Certificates from Acmetek, a Symantec Strategic/Platinum Distributor.

Become a Partner and create additional revenue stream while the heavy lifting for you.

What is SHA1 and why is it being depreciated?

Security always needs to be a proactive campaign. Not updating or keeping up with the progress of technology will open doors in security and will leave businesses open to be hacked.

SHA1 was the Algorithm that was used to create and sign encryption keypairs that are used to scramble data on websites, and applications. SHA1 was a replacement for MD5, and now SHA2 is the replacement for SHA1.

The CA/Browser Forum, is the governing entity of leading web browsers and certificate authorities (CAs) working together to stay proactive with security and publish their Baseline Requirements for SSL regarding the security standards of the web industry. These Requirements recommend that all CAs transition away from SHA-1 as soon as possible, and to discontinuing issuing SHA1 public facing certificates. The reason being that due to the progress of technology this old algorithm is on the verge of being exploited.

Browser’s like Internet Explorer, Firefox and Chrome are inforcing these standards but placing errors within their browsers associated with these standards. According to Google’s “Gradually Sunsetting SHA-1”, Chrome version 39 and later will display visual security indicators on sites with SHA-1 SSL certificates with validity beyond January 1, 2016.
In short:
Most browsers will not trust certificates that use SHA1 After 12/31/2016.

If you do not want to get an error on your website you will have to replace that old SHA1 certificate with a newer SHA2.

 

How to Replace your old SHA1 certificate with SHA2?

To do list:

1. Identify certificates that have a SHA-1 algorithm. Since the standard is already in effect you would definitely know if you still have a SHA1 certificate from the browser errors you would be getting in chrome.
2. Contact your Certificate Authority for procedures in replacing any SHA-1 certificates with the SHA-2 certificates.
   Note: If your SSL certificate was issued through Acmetek Click HERE.
   
3. Install your new SHA2 SSL Certificate to your server.
4. Test your SSL installation by using an SSL Checker.

These standards are always changing. Especially with how fast new technologies are coming out. SSL Certificates are a method of enforcing industry standards to make a more secure internet for everyone.

---

About SSLSupportDesk:

SSLSupportDesk is part of Acmetek who is a trusted advisor of security solutions and services. They provide comprehensive security solutions that include Encryption & Authentication (SSL), Endpoint Protection, Multi-factor Authentication, PKI/Digital Signing Certificates, DDOS, WAF and Malware Removal. If you are looking for security look no further. Acmetek has it all covered!

Contact an SSL Specialist to get a consultation on the Website Security Solutions that can fit your needs.

Become a Partner and create additional revenue stream while the heavy lifting for you.

Acmetek’s Platinum Partnership with the worlds leading Certificate Authorities (CA’s) Symantec and Thawte are able to bring to Acmetek Clients a Free domain SAN with the enrollment
of an SSL/TLS Certificate.

 

This means your website will work when your clients visit your website by either www or without. No more forwarding of website traffic or paying extra for an extra Subject Alternative Name (SAN) domain. Something that should automatically come by default. Many CA’s the world over do not provide this functionality to their clients which causes a technical nightmare to web developers, and Network administrators. But Acmetek is able to provide you with a simpler solution.

Here is how it works:

1. When enrolling for a standard Symantec or Thawte SSL product with a Certificate Signing Request (CSR) Common Name of www.domain.com (example) Symantec/Thawte will automatically add the base domain of domain.com as a free SAN to the certificate.
2. If the Common Name of the CSR has only domain.com then Symantec/Thawte will automatically add www to the Certificate.
3. For Wildcard Certificates products, when your CSR has the Required Common Name of *.domain.com, Symantec/Thawte will add the base domain of domain.com as a free SAN.

Products benefiting from free SAN from this change:

Symantec	Thawte
Secure Site Pro with EV	SSL Web Server with EV
Secure Site with EV	SGC SuperCerts
Secure Site Pro	SSL Web Server Wildcard
Secure Site Wildcard	SSL Web Server
Secure Site	SSL123

SSL/TLS Certificates are the first step in maintaining a secure website or network for your business. Symantec product especially contain the right tools along with with their Products to give you an overall security soltuion. Read more about Symantec and Thawte website security solutions on our site!

Symantec

Thawte

Acmetek is always brings the best security solutions to fit our clients needs. Our partnerships and tools are dedicated to providing easy solutions in website security.

---

Lead Engineer: Dominic Rafael
dsrafael@acmetek.com

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

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