As part of a long-term effort to simplify Symantec’s product range and ensure their offerings are relevant to the latest security needs, Symantec is discontinuing (End of Life) their Symantec Safe Site product as of March 2016.

Symantec Safe Site (formally the VeriSign Trust Seal) is the stand-alone seal product which allows a user to display the seal without having to purchase an SSL certificate.

Note: There will be no impact on the Norton Secured Seal included in SSL certificate products.

Symantec Safe Site End of Life FAQ:

What should I do?
In order to continue displaying the Norton Secured Seal on their website, you will need to purchase one of our Symantec SSL products. Any Symantec Safe Site customer who chooses not to upgrade will lose their existing Symantec Safe Site at the end of their current product’s current term.

Why is Symantec discontinuing Symantec Safe Site?
Symantec want’s to simplify their product range, so they plan to eliminate smaller products that essentially have become redundant. Symantec Safe Site has been marked as a product that is not essential in their range and can be discontinued. Symantec SSL offers the same Norton Secured Seal, plus additional features that more comprehensively protect websites and simultaneously project trust.

Does this affect the seal on any other products?
No, the seal for all other products will still be available. No changes will be made.

What will happen if I don’t want another product?
Customers will not be able to renew their Symantec Safe Site product once their term is complete, so at that time they will no longer have access to the Norton Secured Seal nor Malware Scanning.

We suggest you upgrade to Symantec SSL to continue reaping the benefits you clearly value from the Norton Secured Seal, in addition to the added website security that comes with an SSL certificate.

If you currently have an SSL certificate but are not displaying the Norton Secured Seal visit our SSLSupportDesk article: Norton Secured Seal Installation Instructions

---

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.

Memorandum Requires Secure Connections across Federal Websites and Web Services.

Signed June 8th 2015 The Executive Office Of The President has enacted memorandum M-15-13. Also known as The HTTPS-Only Standard that requires that all public accessible Federal websites and web services only provide service through a secure connection.

This is very important as unencrypted HTTP connections create a privacy vulnerability and expose potentially sensitive information about users of unencrypted Federal websites and services. Any data sent over HTTP is susceptible to interception, manipulation, and impersonation. This data can include browser identity, website content, search terms, and other user-submitted information.

“All browsing activity should be considered private and sensitive.”

Many commercial organizations have adopted HTTPS or implemented HTTPS-only policies to protect visitors to their websites and services. Users of Federal websites and services deserve the same protection, and the Federal Government needs to set a presidence that in this day-and-age Web Security is as important as the air we breathe.

Although the challenges are few there are some considerations and implementations of HTTPS that may have effect on these Federal Government Services.

Challenges and Considerations:

Site Performance: While encryption adds some computational overhead, modern software and hardware can handle this overhead without substantial deleterious impact on server performance or latency.

Server Name Indication: The Server Name Indication (SNI) extension to SSL/TLS allows for more efficient use of iP addresses when serving multiple domains. However, these technologies are not supported by some legacy clients. An example of SNI also known as Fully Qualified Domain Name (FQDN) would be www.energy.gov.

Mixed Content: Websites served over HTTPS need to ensure that all external resources (images, scripts, fonts, iframes, etc.) are also loaded over a secure connection. Modern browsers will refuse to load many insecure resources referenced from within a secure website. When migrating existing websites, this can involve a combination of automated and manual effort to update, replace, or remove references to insecure resources. For some websites, this can be the most time consuming aspect of the migration process.

APis and Services: Web services that serve primarily non-browser clients, such as web APis, may require a more gradual and hands-on migration strategy, as not all clients can be expected to be configured for HTTPS connections or to successfully follow redirects.

Planning for Change: Protocols and web standards improve regularly, and security vulnerabilities can emerge that require prompt attention. With that said Admin may have to be upgrade their system typologies in order to meet this standard. Federal websites and services should also deploy HTTPS in a manner that allows for rapid updates to certificates, proper cipher choices.

One standard that has effected legacy systems that will need to be taken into account is the SHA2 standard due to the SHA1 vulnerability that has taken effect in the commercial browser industry. For Example, old Microsoft IIS6 (Server 2003) systems lack the ability to understand the SHA2 algorithm due to its 12 year outdated software. Federal web service admins should evaluate the feasibility of using technology to improve performance efficiency and may have to upgrade their infrastructure as soon as possible.

In order to secure and implement HTTPS a Digital Server Certificate will have to be issued to the SNI/FQDN for that implemented HTTPS Web Service. Issued by a Trusted Authority.

The Office of Management and Budget (OMB) affirms that tangible benefits to the American public outweigh the cost to the taxpayer. Implementation of Server Certificates with HTTPS will help fight unofficial or malicious websites claiming to be Federal services, and block hacker eavesdropping on communications with official U.S. government sites.

Acmetek Global Solutions, Inc. is very familiar with the standards of the industry and have the Managed PKI solutions & recommendations needed to assist Federal/State government agencies on matters of Web Network Security.

---

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.

Symantec will be discontinuing the availability of its External Certificate Authority ECA Certificates offering. Symantec is phasing out this offering as follows:

 

August 16, 2016 – End of Sale: Symantec will stop selling the ECA offering. No new ECA certificates will be issued.

August 16, 2016 – End of Renewal: Symantec will stop renewals for all the existing certificates.

August 17, 2017 – End of Life: All certificates will expire or are revoked. Symantec ECA operations will cease.

What is a ECA Certificate?

Symantec was certified by the United States Department of Defense (DoD) as a provider of External Certification Authority (ECA) digital certificates for government contractors, state and local governments and employees of foreign governments. ECA certificates enable secure on-line transactions with DoD agencies, digitally signing documents, and encrypting e-mail communications.

Who does this effect?

If you are not interacting with the Department of Defense then this will not effect you. This only effects those who do business or work for the DoD digitally in order to gain access to DoD systems. If you do work for the DoD ask the proper DoD IT security agent for more information. More than likely though you should have received some sort of information if this directly effects you from an DoD entity.

If you need more information and to stay up to date on the Symantec ECA and its End of Life visit

https://www.symantec.com/products/information-protection/eca-certificates

---

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.

End of Life Announcement for Symantec Digital ID for Secure Email

Symantec will be discontinuing the availability of its Digital ID for Secure Email offering. To ease this transition, Symantec is phasing out this offering as follows:

August 22, 2016 – End of Sale: Symantec will stop selling the Digital IDs offering. No new certificates will be issued.

August 23, 2017- End of Life & End of Support: All certificates will expire or are revoked. Symantec Digital IDs for Secure Email support and operations will cease.

Why? For a more secure world of course

The retail versions of the Symantec Digital IDs for Secure Email did not accurately authenticate clients. When the Digital ID certificate would get issued Symantec placed “Persona Not Validated” in the Common Name field of these certificates because Symantec does not verify that the individual registering the email is indeed legally recognized by that name. Because this ID is not validated, to separate these certificates from those that are validated through a notary enrollment process, they are designated as not validated.

Example:

Authentication procedures cannot prove that the retail enrolled person for the digital ID is indeed JON DOE with an email of likescheese@mailcom. Thus why the certificates in the common name would state “Persona Not Validated“

Alternatively, customers can purchase an ENTERPRISE offering (NOT the RETAIL offering) to protect digital communication. These User Authenticated notarized certificates accurately state a users name for which they are issued to because of validated checks that are performed within the enrolled organization.

Digital IDs for Secure Email (Class 1) Support can be found here and any concerns can be address by sending an email to id-queries@symantec.com

What do User Digital IDs Do in General?

Compromised email can mean loss of IP and damage to reputation. A digital ID is like an electronic driver’s license or passport that proves your identity. Digital IDs allow you to digitally sign and encrypt your digital communications using a certificate, bound to your validated email address.

Use Digital IDs to:

• Digitally sign email: A red ribbon icon on the email indicates it came from a valid email address.
• Encrypt email: A blue envelope icon on the email indicates it remained private during transmission (only the recipient can securely open it).
• General signature and encryption: Microsoft Word allows for digital signing of Word documents.
• In Enterprise environments it Authenticates digitally the holder of the certificate to be used and gain access to applications or network environments.

---

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.

GoDaddy last week has begun the process of re-issuing SSL certificates for more than 6,000 customers after a bug was discovered with there DV (Domain Validated) automated registrar’s validation process. This automated process of getting a certificate is one of the fastest ways of getting a validated digital certificate used to encrypt and validate websites or networks.

“GoDaddy inadvertently introduced the bug during a routine code change intended to improve our certificate issuance process. ” “The bug caused the domain validation process to fail in certain circumstances.” Thayer VP and General Manager of Security Products at GoDaddy said in a statement.

When we hear terms such as “Improve Certificate Issuance Process” it usually means make things faster, or more automated. Keep in mind that GoDaddy is not a security company they are into hosting. Being a Certificate Authority (CA) is just a by product of the service they provide. The issue exposed sites running SSL certs from GoDaddy to spoofing where a hacker could gain access to certificates and pose as a legitimate site. Enabling a hacker the spread of malware, or steal personal information such as Banking login credentials. This move to “Improve” a certificate issuance comes from fear from a new free CA that has debut called Let’s Encrypt.

Let’s Encrypt is a free, automated, and open CA brought to you by the non-profit Internet Security Research Group (ISRG). The move for this free automated process is to help the industry migrate to enable HTTPS(SSL/TLS) for websites in the most user friendly way possible. It is meant to significantly lower the complexity of setting up and maintaining TLS encryption.

Features of Let’s Encrypt.

• Let’s Encrypt issues Only domain-validated certificates, since they can be fully automated. Organization Validation and Extended Validation Certificates are not available.
• Let’s Encrypt issues certificates valid for 90 days. Their reason is that these certificates “limit damage from key compromise and mis-issuance” and encourage automation. The official certbot client and most of the third-party clients allow automation of the certificate renewal.
• Only Open Source Linux systems are capable with Lets’Encrypt automation.
• No wildcard functionality (currently).
• Elimination of payment, web server configuration, validation email management and certificate renewal tasks.

The Ugly/Disadvantages:

• One disadvantage that makes big companies Not consider Let’s Encrypt is that visitors that connect to the site can’t be sure that it is the actual company that hosts the site. This is because Let’s Encrypt issues DV certificates for a domain free of charge without identity validation (personal or corporate)
• Automatic renewal of these certificates tends to lead IT admins to neglect security upkeep’s on there systems. Majority of the time when an admin is made to visit a system due to a certificate needing an update they discover that they are out of compliance with needed patches and configurations. This can lead to backdoor hacking due to dated software and standards if left untouched.
• The free cost of these certificate allows hackers to achieve a certificate. The potential for Let’s Encrypt being abused by those who can freely get these certificates are very present. Hackers tend to not want to spend money to achieve their goals.

Any technology that is meant for good can be abused by cyber criminals, and digital certificates like those of Let’s Encrypt’s are no exception. This trust system can be abused. There is one reported case where an attacker/malvertiser was able to perform a technique called “domain shadowing.” Domain shadowing is when the attacker is able to create sub domains under the legitimate site. With an embedded advertisement on a website an end user could click on a malicious add thinking that they are visiting an alternate page. In reality though they have been lead to the hackers malvertising server which could download a trojan or Randsomeware into that users system. A certificate authority that automatically issues free certificates specific to these sub-domains may inadvertently help cyber criminals, all with the domain owner being unaware of the problem and unable to prevent it.

Domain-validation certificates only confirm that the relevant domain is under the control of the site recipient. In theory, this will not validate the identity of the recipient. End users that visit these sites are unaware of the nuances of certificates may miss the differences, and as a result, these DV certificates can help the hacker gain legitimacy with the public. There is nothing wrong with the procurement of a DV certificate. Depending on the circumstances DV is advised for internal networks when there is a need for a quick cost effective resolution. Security is always is a Pro-Active industry. Cutting corners and making things easy for the sake of convenience is a double edge sword, and could lead to a loss of business and good reputation. Needless to say approach with caution.

---

Posted by:
Dominic Rafael
Lead Tech Solutions Engineer
Be sure to Subscribe!!
twitter

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.