• The Ultimate WordPress Plugin Security Testing Cheat Sheet

        Oct 20 2017, 8:40 PM

        by larsonr eever 2

        The security documentation provided by WordPress and found online for plugin security is sparse, outdated or unclear. This cheat sheet is intended for Penetration Testers who audit WordPress plugins or developers who wish to audit their own WordPress plugins. This cheat sheet can be effectively used to test various WordPress plugins.

        Cross-Site Scripting (XSS)

        Check if the following global PHP variables are echo'd to pages, or stored in the database and echo'd at a later time without first being sanitised or output encoded.

        • $_GET
        • $_POST
        • $_REQUEST
        • $_SERVER['REQUEST_URI']
        • $_SERVER['PHP_SELF']
        • $_SERVER['HTTP_REFERER']
        • $_COOKIE

        (Note: the list of sources above is not extensive nor complete)

        Cross-Site Scripting (XSS) Tips

        Unsafe API functions

        The following functions can cause XSS if not secured:

        • add_query_arg()
        • remove_query_arg()

        See References Below:


        When doing dynamic testing for XSS the following setting in the wp-config.php file may reduce false positive results as it prevents administrative and editor users from being able to embed/execute JavaScript/HTML, which by default they are permitted to do.

        define( 'DISALLOW_UNFILTERED_HTML', true );

        SQL Injection

        Unsafe API methods (require sanitising/escaping):

        • $wpdb->query()
        • $wpdb->get_var()
        • $wpdb->get_row()
        • $wpdb->get_col()
        • $wpdb->get_results()
        • $wpdb->replace()

        Safe API methods (according to WordPress):

        • $wpdb->insert()
        • $wpdb->update()
        • $wpdb->delete()

        Safe code, prepared statement:

        <?php $sql = $wpdb->prepare( 'query' , value_parameter[, value_parameter ... ] ); ?>

        Note: Before WordPress 3.5 $wpdb->prepare could be used insecurely as you could just pass the query without using placeholders, like in the following example:

        $wpdb->query( $wpdb->prepare( "INSERT INTO table (user, pass) VALUES ('$user', '$pass')" ) );

        SQL Injection Tips

        Unsafe escaping ('securing') API methods:

        • esc_sql() function does not adequately protect against SQL Injection - see refs below
        • escape() same as above
        • esc_like() same as above
        • like_escape() same as above

        Displaying/hiding SQL errors:

        <?php $wpdb->show_errors(); ?> <?php $wpdb->hide_errors(); ?> <?php $wpdb->print_error(); ?>

        File Inclusion

        • include()
        • require()
        • include_once()
        • require_once()

        PHP Object Injection

        • unserialize()

        Command Execution

        • system()
        • exec()
        • passthru()
        • shell_exec()

        PHP Code Execution

        • eval()
        • assert()
        • preg_replace() dangerous "e" flag deprecated since PHP >= 5.5.0 and removed in PHP >= 7.0.0.


        • is_admin() does not check if the user is authenticated as administrator, only checks if page displayed is in the admin section, can lead to auth bypass if misused.
        • is_user_admin() same as above
        • current_user_can() used for checking authorisation. This is what should be used to check authorisation.

        Open Redirect

        • wp_redirect() function can be used to redirect to user supplied URLs. If user input is not sanitised or validated this could lead to Open Redirect vulnerabilities.

        Cross-Site Request Forgery (CSRF)

        • wp_nonce_field() adds CSRF token to forms
        • wp_nonce_url() adds CSRF token to URL
        • wp_verify_nonce() checks the CSRF token validity server side
        • check_admin_referer() checks the CSRF token validity server side and came from admin screen


        • CURLOPT_SSL_VERIFYHOST if set to 0 then does not check name in host certificate
        • CURLOPT_SSL_VERIFYPEER if set to FALSE then does not check if the certificate (inc chain), is trusted
        • Check if HTTP is used to communicate with backend servers or APIs. A grep for "http://" should be sufficient.

        Further reading/references:


        • Tip How to
        • Security Risks
        • DigiCert Code Signing
        • Error messages
        • Vulnerabilities & Exploits
        • Best Practice
        • Products
        • Malware Scan
        • Vulnerability Assessment
        • Symantec Website Security
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Managed PKI for SSL
      • CAA checking: what is it, and why should it be mandatory?

        May 22 2017, 10:29 PM

        by Rufus Connell 0

        The Public Key Infrastructure (PKI) ecosystem relies on root certificates issued by various certification authorities (CAs) like Symantec. This is what browsers use to decide which websites can be trusted, and which ones can’t.

        Currently, any CA can issue a TLS certificate for any domain. That’s how the system works, and it’s good in the sense that it gives website owners choice; they can change CAs if they want to. But the downside is that unregulated certification can lead to ‘mis-issuance’, either by mistake or by rogue CAs.

        A number of technologies have been created in an attempt to limit instances of miscertification, such as Certificate Pinning and Certificate Transparency. These have been effective in making the internet a safer, more trustworthy place but they’re reactionary. Both are only able to address mis-issuance after it’s happened.

        But is it possible to prevent certificates from being mistakenly or inappropriately issued? Yes. Enter: Certification Authority Authorization (CAA).

        CAA prevents mis-issuance by:

        1. allowing domain owners to specify which CAs are authorized to issue certificates for their domains; and
        2. giving CAs the ability to check this authorization before issuing a certificate.

        In this article we’ll explain how CAA works, and why making CAA checking mandatory is a good move for both customers and CAs.

        What is Certification Authority Authorization?

        A Certification Authority Authorization (CAA) record is a DNS Resource Record. It allows a domain owner to specify which CAs are authorized to issue certificates for their domain and, by implication, which aren’t.

        The idea is that a CA will check the CAA record(s) for a domain before issuing a certificate. If it finds that a domain has no CAA record, then it’s free to issue a certificate for it if all other validation checks succeed. However, if it does encounter one or more records, then the CA can only issue a certificate if it’s named in one of the records, indicating that it is authorized to issue a certificate for that domain. The whole process is designed to prevent CAs from inappropriately or mistakenly issuing TLS certificates.

        Sounds great. Why isn’t everyone doing this?

        Symantec has been checking CAA records for years, but it’s not a common practice. There are two reasons why CAA checking isn’t widely practiced:

        1. many domains don’t have a CAA Resource Record; and
        2. checking the record is not mandatory.

        Because it may take some work to create a CAA record, it’s a matter of consciously opting-in, not opting-out. Many domain owners use a DNS hosting provider and CAA is not yet supported in some DNS implementations.

        This is why CAA records are expected to be used by most high-value domains. These enterprises keep CAA records for their domains because it limits inappropriate (or malicious) certificate requests, and makes it easier to enforce company policies i.e. only using a particular set of CAs.

        The limitations of CAA checking

        Of course, CAA checking has its limitations.

        For one thing, a newly-issued CAA record does not invalidate any previously-issued certificates that may have been issued by a different CA than the one named by the domain owner. Secondly, it doesn’t flag whether a certificate presented by a web server is a legitimate certificate for that domain.

        Furthermore, in order for CAA checking to be effective, all CAs need to be doing it; it doesn’t work if only one or two CAs are checking CAA records as matter of process. CAA checking must be widely adopted if it is to serve its purpose, but the good news is that more than ninety percent of CAs (who are members of the CA/Browser Forum) are in favor of it.

        The times are changing: CAA checking will become mandatory

        In February 2017, the CA/Browser Forum passed a motion (on which Symantec voted in favor) requiring all CAs (even those who aren’t a member of the Forum) to check for a CAA record as part of the certificate issuance process for each domain. In accordance with RFC 6844, CAs can no longer issue a certificate for a domain unless:

        1. The CA does not find any CAA records for the domain
        2. The certificate request is consistent with the applicable CAA Resource Record(s)

        The rule is effective as of 8 September 2017. You can read the motion in full here.

        A good outcome for all companies

        Mandatory CAA record checking requires CAs to abide by the rules set out in specific CAA records, giving domain owners more control over certificate issuance. This makes it easier for companies (especially larger ones) to enforce a certificate issuance policy across business units. With CAA records applicable to every domain, a company can whitelist a set number of CAs, knowing no other authority can issue a certificate. 

        On a broader level, the new rules will mean that CAs can properly reconcile a certificate request at the domain owner’s discretion, holding themselves accountable for any mis-issuance. At Symantec, we believe this is an important step towards a securer, more transparent online ecosystem.

        • Products
        • DigiCert Code Signing
        • Symantec Website Security
        • Best Practice
      • The importance of orchestrated “cloud” security

        Feb 23 2015, 7:43 PM

        by Dion Alken 6

        The importance of orchestrated “cloud” security

        In today’s digital world, the area of security and safety has become paramount. Cybercrimes are on the rise and are becoming more sophisticated. We could be experiencing “a new era in cybercrime”.

        In 2015 we already had some interesting cases:

        This week it was revealed that the Carbanak malware used by the cyber-criminals proved to be very successful in helping the attackers steal around $1 billion. Researchers are worried about the increasing sophistication of attacks.

        Despite increased awareness of cybercrime within the financial services sector, it appears that spear phishing attacks ( and the old exploits (for which patches have been disseminated) remain effective against larger companies. Attackers always use this minimal effort approach in order to bypass a victim ́s defences

        Researchers said: “the most highly sophisticated criminal attack we have ever seen.”  “It’s like an arms race. Security companies develop better protection and criminals develop better malware to bypass it,”

        While early versions of Carbanak (!/blogs/carbanak-multi-million-dollar-cybercrime-gang-focuses-banks-rather-their-customers)  were based partially on code from Carberp (!/blogs/new-carberp-variant-heads-down-under),  the latest versions do not appear to use any Carberp source code. In 2013 Russian authorities claimed to have captured the mastermind behind the Carberp banking Trojan and other members of this criminal gang.

        The cybercrime ring, led by a 28-year old Russian national, allegedly had been in operation since 2009 and has stolen approximately $250 million from Ukrainian and Russian banks, according to an April 2013 report from Kommersant Ukraine, a national publication.

        In March 2012, authorities arrested and broke up a gang that used Carberp to steal $2 million from over 90 individual bank accounts. That cybercrime gang used the malware and was not responsible for developing the Trojan. The black-market price for the malware was between $5,000 and $50,000.

        Then there are new developments in enterprise level threats with a “cyber-warfare” character.

        The designers of Stuxnet ( have further developed new malware that can enter into the firmware of hardware and is able to effect the heart of the computer – The Bios-code ( The Equation group is a highly sophisticated threat actor that has been engaged in multiple CNE (computer network exploitation) operations dating back to 2001, and perhaps as early as 1996. The Equation group uses multiple malware platforms, some of which surpass the well-known “Regin” (!/blogs/regin-top-tier-espionage-tool-enables-stealthy-surveillance)  threat in complexity and sophistication. The Equation group ( is probably one of the most sophisticated cyber-attack groups in the world; and they are the most advanced threat actor we have seen.

        So far, we’ve identified several malware platforms used exclusively by the Equation group. They are: • EQUATIONDRUG – A very complex attack platform used by the group on its victims. It supports a module plugin system, which can be dynamically uploaded and unloaded by the attackers.

        • DOUBLEFANTASY – A validator-style Trojan, designed to confirm the target is the intended one. If the target is confirmed, they get upgraded to a more sophisticated platform such as EQUATIONDRUG or GRAYFISH.

        • EQUESTRE – Same as EQUATIONDRUG.

        • TRIPLEFANTASY – Full-featured backdoor sometimes used in tandem with GRAYFISH. Looks like an upgrade of DOUBLEFANTASY, and is possibly a more recent validator-style plugin.

        • GRAYFISH – The most sophisticated attack platform from the EQUATION group. It resides completely in the registry, relying on a boot kit to gain execution at OS start-up.

        • FANNY – A computer worm created in 2008 and used to gather information about targets in the Middle East and Asia. Some victims appear to have been upgraded first to DoubleFantasy, and then to the EQUATIONDRUG system. Fanny used exploits for two zero-day vulnerabilities which were later discovered with Stuxnet.

        • EQUATIONLASER – An early implant from the EQUATION group, used around 2001-2004. Compatible with Windows 95/98, and created sometime between DOUBLEFANTASY and EQUATIONDRUG.

        So are there more threats? Yes.

        Are VPNs and VoIP sessions also targeted at an industrial scale? Yes.

        In 2014 it was revealed that malware on systems is spreading automatically via social networks like for example fake Facebook servers, as to infect millions of computers. Electronic infiltration methods for industrial-scale exploitation have therefore aggressively scaled.

        Large arsenals of imaginatively named malware, to remotely control computers and to capture data from them, as well as to interrupt their operation are now revealed.

        For example:

        UNITEDRAKE is modular malware that can take complete control of infected computers.

        CAPTIVATEDAUDIENCE hijacks computer microphones and records conversations.

        FOGGYBOTTOM snatches web browser history files, and login details for sites and email accounts.

        GUMFISH controls webcams and takes photographs.

        SALVAGERABBIT can capture data from external drives.

        GROK is a key logger.

        QUANTUMSKY blocks access to specific websites.

        QUANTUMCOPPER corrupts targets' file downloads.

        By using malware deployed in network routers. Access can be gained to data passing through virtual private networks. The HAMMERSTEIN man in the middle malware appears to attack the Internet Key Exchange (IKE) phase used to set up secure VPN sessions, and attempts decryption of content.

        In a similar manner, the HAMMERCHANT router implant can compromise Voice over Internet Protocol communications, capturing Session Initiation Protocol (SIP/H.323) signalling used to set up calls as well the Real Time Protocol (RTP) data streams for the content.
        Vulnerabilities in web browsers, the Oracle Java and Adobe Flash frameworks, and router software are used to infect devices. The "man in the middle" (MITM) technique, whereby software is secretly placed on networks between computers communicating with each other is a favourite technique of hackers. MITM allows multiple devices to be targeted and also makes it easier to capture the data they transmit.


        What can we do as consumers, businesses and governments?

        Firstly we need to understand that communication between sender and receiver has always been vulnerable.

        We cannot rely on an encryption or antivirus alone. As an IT manager, it is interesting to know that more than half a billion (552 million) identities were exposed in 2013 as a result of data breaches. As malware designers are developing technologies on more vulnerability then we ever had. Users, Companies and Governments need to expect that their information is treasure booty for targeted and automated attacks.

        Symantec can help with the complete security and information management orchestration incorporating up to date cloud security solutions

        Depending on your needs our team will be able to orchestrate the optimal solution for you.

        Progress in malware can be countered by the latest security research and advances in security and compliance for devices and websites.

        Let our Symantec help you build your castle!

        • Security Risks
        • Endpoint Encryption
        • Malicious Code
        • DigiCert Code Signing
        • Emerging Threats
        • Evolution of Security
        • Vulnerabilities & Exploits
        • Protection Engine for Cloud Services
        • Products
        • Control Compliance Suite
        • DeepSight™ Technical Intelligence
        • Enterprise Security Manager
        • Malware Scan
        • Online Fraud
        • Internet Security Threat Report
        • Vulnerability Assessment
        • LiveUpdate
        • Symantec Website Security
        • Data Center Security
        • encryption
        • DigiCert SSL TLS Certificates
        • Endpoint Protection
        • Web
      • SSL Certificates Product Family

        Feb 04 2015, 5:16 PM

        by Cynthia Francis 0



        Symantec Website Security Solutions has an extensive SSL certificate product offering. Whether you need 1 certificate or 15,000 and enterprise management, we’ve got a product that’s perfect for your business – both today and tomorrow as your business grows. Symantec SSL, formerly from VeriSign, provides the strongest encryption available.




        * Content restricted.  Please log into and/or join the Customer Trust Portal group.

        Return to the Customer Trust Portal

        • Products
        • DigiCert Code Signing
        • Symantec Website Security
      • Whitepaper - Simplify SSL Certificate Management Across the Enterprise

        May 28 2014, 5:32 PM

        by Mithun Sanghavi 8

        The need for SSL Certificates has moved well beyond the “buy” page to core functions of the enterprise. SSL Certificates are used to protect remote employee and partner communications via webmail, chat and IM. Browser-to-server communications for cloud-based services require SSL Certificates when used to display customer account information, business partner transactions and for employee productivity tools. Finally, SSL Certificates are used to secure server-to-server communications for applications and data exchange. Managing individual Certificates across a large organization quickly becomes complicated with multiple locations, many divisions, and rapidly growing Web-based services. If an SSL Certificate expires, a company not only loses sales and puts customer confidence in jeopardy, employees and business partners may not be able to do their work or risk exposure of confidential information. Managing SSL Certificates across complex networks to ensure protection and prevent unanticipated expirations has become mission critical to all businesses.
        This guide provides five simple steps for IT professionals to take control of SSL across the enterprise, and recommendations for a management platform for full visibility and single-point of  control for these Certificates throughout their lifecycle.
        To know more check the attached Whitepaper.

        • Products
        • DigiCert Code Signing
        • Tip How to
        • Features
        • Symantec Website Security
        • Best Practice
      • Obtaining and Applying a VeriSign Remote Configuration Certificate

        Mar 29 2018, 9:49 PM

        by Terry Cutler 27

        In previous articles, such as Frequently Asked Questions about Remote Configuration, the topic of remote configuration for the Intel® vPro™ technology was discussed. The core purpose of this approach is to provide remote authentication, thus allow the provisioning or configuration of the technology without physically touching supported Intel® vPro™ technology clients. For delayed provisioning or post deployment provisioning situations, this becomes especially useful.

        However, there is a core requirement which most IT professionals managing client computers typically do not deal with: obtaining an external x.509v3 certificate from a trusted certificate authority. The process is actually quite simple and does not require a deep understanding of certificates, PKI, and so forth. If your IT department has a certificate specialist, share the article linked above with them and they will likely have the certificate purchased before you get back to your desk (figuratively speaking).

        For the rest of us - the key question keeps getting raised - "How do I purchase and install a remote configuration certificate?" This article addresses the steps to acquire a VeriSign certificate for the purpose of remote configuration, and will be using the Microsoft Internet Information Server (IIS) version 6 to generate the certificate signing request (CSR). There are other processes and methods to generate the CSR, but I will only be showing one in this article. Similar processes would be followed for GoDaddy, Starfield, Comodo, or other remote configuration certificates supported by the target platform. Although there is a cost associated to acquiring the certificate, it is often minimal in light of the cost of touching every system for distribution of security keys - whether by yourself or via a paid service to perform such activities. With that - it should be noted that remote configuration is NOT for everyone and every situation.

        If you read the Intel® vPro™ Expert article posted at, the FAQ in the article linked above, and are still scratching your head - this article ought to help out.

        Overview of the Basic Steps

        Obtaining the certificate requires the following steps:

        1. Generate a Certificate Signing Request (CSR) to be sent to the Certificate Authority (e.g. VeriSign). This will also generate the private key which will be stored on your server.
        2. Receive the signed request from the Certificate Authority. This is usually in a .CER file
        3. Complete the CSR using the received .CER file to associate your private key to the signed request
        4. Export and backup the issued certificate with associated certificate chain to a .PFX file
        5. Import the certificate into the Load Computer certificate store
        6. Do a visual check of the certificate and associated certificate path to ensure the correct properties have been applied
        7. Run the LoadCert.exe utility to complete the association of the certificate to the provisioning service.

        Core Considerations of the Certificate

        As a review to the core certificate properties referenced in the above linked article, there are a few items to be aware of before purchasing the certificate:

        • The desired certificate must have a matching root certificate hash (aka thumbprint) preloaded in the Intel® vPro™ firmware. This is mentioned in the article linked above. Environments wanting to "generate their own certificate" can do so IF they can load their root certificate into the firmware. (However, you have to ask yourself a question there. If you are already touching the system to enter a certificate hash - then why not use pre-shared key?)
        • What is the DHCP option 15 setting in your environment? Can you prove ownership of the DNS suffix used? (more on this later).
        • Does the DNS domain suffix have a parent or child domain for the clients you will be provisioning? For example, the DNS suffix is, yet you want to provision clients in and The key is understanding the match between the DHCP option 15 and the DNS suffix , this will determine how many certificates you need to purchase. If more than one - the next two items must be understood.
        • How many "provisionserver" systems will be in the environment? This is the Altiris Notification Server with Out of Band Management, which is hosting the Intel® vPro™ provisioning service capabilities. If you have more than one client facing Altiris NS Server to be used as a "ProvisionServer", take a look at the articles linked from Using Out of Band Management with Intel SCS in a Multiple Notification Server Environment.
        • The present provisioning service will allow only ONE certificate to be associated to it. Therefore, if your environment requires multiple certificates due to different DNS domain suffixes or other reasons, then it is a question of mapping the intended certificate to the target ProvisionServer. This will change in future versions of the provisioning service, yet for now - it is a ONE to ONE mapping for Intel SCS 3.x environments.
        • Once imported to the Local Computer Store, the AMTconfig service logon account must have access to the private key for encryption of the messages. If this account does not have access, then the certificate must also be imported to the Service account's certificate store.

        Ok - are you ready to start?

        Generate the Certificate Signing Request (CSR)

        For Microsoft IIS 6.0 environments, follow the basic steps provided by VeriSign at In short, access the IIS WebSites, right click on Default Web Site, and select Properties. Within the Properties window, select the Directory Security tab, followed by Server Certificates.

        You will be prompted to create a new request, among other items.

        • Select Create a new certificate request, and step through the screens to Prepare the request now, but send it later.
        • When prompted for a Name, enter a value to quickly identify the certificate. This screen will also show the maximum encryption key size. Remote Configuration supports a maximum 2048 key.
        • When prompted for Organization, enter the DNS context you intend to use. The example below is MyCompany.local
        • When prompted for the Organizational Unit enter Intel(R) Client Setup Certificate. Note that (R) is used instead of ®.
        • When promoted for the site's common name, enter the FQDN of the target server. This value could also include a placeholder hostname is needed. The more important piece is the DNS suffix specified.
        • When the necessary data has been entered, a .TXT file will be created to be sent to VeriSign. The following screen shows a summary of the core values within the .TXT file.

        Submit the CSR to VeriSign

        Access the VeriSign SSL certificate purchasing site at On the Buy SSL Certificates page, locate the Secure Site: SSL Certificates section and click Buy.

        On the Select Options page, do the following:

        1. Select how many years you wish purchase (validity period).
        2. Enter the number of servers to be secured with this certificate.
        3. Specify whether the server is located outside of the USA/Canada.
        4. Click Continue.

        On the Select a level of security page, select a server type and paste the contents of the previously generated .txt file. The contents should look similar to what is shown below. Be sure to use Notepad or other viewer that does not add in extra characters or formatting.

        On the Contacts page, enter your contact and payment information. Print your order confirmation for your records and finish the purchasing process.

        IMPORTANT: You will receive an e-mail from VeriSign's automated order verification within few hours. You have only 24 hours, after receiving the e-mail, to finish this process. Click the link in the e-mail and complete the process as detailed below.

        Complete the CSR

        Within a few hours you will receive an email with the signed certificate - both text in the email and likely a .CER file from VeriSign. The text in the email between the BEGIN and END NEW CERTIFICATE REQUEST is the Base64 encoded signed certificate from VeriSign. This certificate needs to be combined with the private key stored on your Microsoft IIS server. Repeat the steps used to generate a new CSR previously described, except this time select Process the pending request and install the certificate.

        It is important that the pending require match the response file. If the pending request was deleted in error, a new CSR must be generated and submitted to VeriSign. VeriSign has a 30-day revoke or replace guarantee.

        Export and Backup the Certificate to a PFX File

        Once the pending certificate request has been completed with the .CER file provided, the target website used for this process has been assigned the issued certificate. However, the Loadcert.exe process and Intel® SCS will be looking for the issued certificate in the Local Computer certificate store. In addition, a backup copy of the certificate is recommended.

        Another method to access the Microsoft ISS Manager is Start > Programs > Administrative Tasks > Internet Information Services (IIS) Manager. Open the IIS Manager and navigate to the website which currently has the issued remote configuration certificate. Access the Properties of the website, select the Directory Security Tab, and select View Certificate under the Secure Communications section.

        With the issued remote configuration certificate opened, select the Detail tab and click Copy to File to initiated the Certificate Export Wizard. In stepping through the wizard, ensure the following options are selected:

        • Yes, export the private key
        • Include all certificates in the certification path if possible

        You will be prompted to provide a password, which will secure the generated PFX file.

        Once completed, you now have a .PFX file providing a backup copy of the issued remote configuration certificate, intermediate certificate, and root VeriSign certificate.

        Import to the Local Computer Certificate Store

        NOTE: The instruction below apply ONLY to Altiris 6 with SCS 3.x environments.   If you are using Altiris 7.x which includes SCS 5.x - please refer to Insight #4 at

        If not already opened, access the Local Computer Certificate store by running mmc.exe (Microsoft Management Console). Within the console, select File > Add/Remove Snap-in. From the list of options, select Certificates. When prompted, select Computer Account followed by Local Computer. Close the Add/Remove Snap-in window to see the certificate folders.

        Navigate to the Personal folder and select Import. In stepping through the Import Wizard, Browse to the .PFX file previously created. When prompted to Select a Certificate Store, choose Automatically select the certificate store based on the type of certificate. This will ensure that the certificates are imported to the correct folder providing the server with the full certificate security chain.

        Visually Inspect the Certificate Properties

        Once the certificate is imported, refresh the screen and open the newly issued certificate. Ensure that the certificate includes the private key, as this will be used to encrypt messages.

        Select the Detail tab, and check the Subject of the certificate. Ensure that the OU entry is Intel(R) Client Setup Certificate, and that the CN entry is the FQDN of the target server.

        Select the Certificate Path tab, and navigate to the Root Certificate which is found at the top of the certificate chain. Double click on the root certificate (e.g. VeriSign Class 3 Public Primary CA).

        Within the Details of the Root Certificate, select Thumbprint. This is the certificate hash unique to this certificate and that has been loaded in the firmware of the Intel® vPro™ technology system. The list of certificate hashes is referenced in the FAQ article mentioned at the beginning of this article.

        Run LoadCert.exe to Complete the Certificate Process

        NOTE: This step ONLY applies to Altiris 6.x environments using SCS 3.x

        With the certificate created, imported, and inspected - one final step remains: associate the issued certificate with the provisioning service. The LoadCert.exe utility located at c:\Program Files\Intel\AMTConfserver\Tools is used to perform this action.

        Run the LoadCert.exe utility. A command window will appear providing brief instructions and a prompt to continue. Select Y and the Select Certificate window will appear showing all certificates in the Personal Folder of the Local Computer Certificate Store. Select the issued certificate, with an option to view the certificate first to validate it is the correct certificate.


        At this point, the provisioning service within the Altiris OOBM server is ready to receive and process remote configuration requests using the issued VeriSign certificate. You will need to ensure Remote Configuration is enabled in the General settings of the Altiris provisioning interface. All remote configuration capable systems have the matching certificate hash preloaded. The certificate must be issued to the DNS context of the clients, which requires a validation of identity during the certificate purchase process.

        With the certificate loaded, initiating of the provisioning process is accomplished via OOB Task Agent with Delayed Provisioning, or via the Intel® vPro™ Activator Utility. More information on each of these can be provided if needed - just make a note to this article.

        The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries.

        • Products
        • 6.x
        • Client Management Suite
        • Compatibility
        • 7.x
        • DigiCert Code Signing
        • DigiCert SSL TLS Certificates