Selling SSL Certificates

RackHelm resells SSL certificates through eNom. A certificate is an ordinary product in your catalogue, but it does not provision in one shot like a hosting account — it is bought, then configured by the customer, then validated by the certificate authority, then issued minutes or days later. This article explains how to set that up and what happens afterwards. It is for operators.

Before you start #

• A working eNom panel. SSL reuses the same eNom reseller credentials — there is no separate SSL panel and no separate key. See Selling domains through eNom.
• SSL products enabled on your eNom reseller account.
• The edit_products permission to build the product, edit_integrations to configure eNom.

Warning: The eNom SSL driver has not been verified against a live eNom account. The exact certificate command parameter names, the numeric product ids, the validation-method tokens and the status strings eNom returns all vary by account and product, and are flagged in the code as needing confirmation against a real sandbox. Place one order end to end before you sell certificates.

Note: eNom is the only SSL provider. NameSilo’s public API has no certificate operations, so NameSilo SSL cannot be automated and is deliberately not offered.

Create an SSL product #

1. Go to Catalogue → Catalogue & Groups → New Product and create the product as usual — name, group, description, pricing.
2. Open the product’s Provisioning tab.
3. Set Integration Type to Enom SSL and leave Enable Provisioning on.
4. Pick the certificate from the SSL Product dropdown. That list is pulled live from your eNom account, showing each product’s description and reseller price.
5. Save.

The Enom SSL option only appears when an eNom panel is active, because it borrows those credentials. The catalogue is cached for six hours; if you enable a new certificate product at eNom it can take that long to appear.

What is derived, not configured #

You do not set the certificate type, wildcard flag or term. They are intrinsic to the eNom product you chose and are derived from its description when the customer buys:

• A description containing “wildcard” marks the certificate as a wildcard.
• “EV” or “extended” gives type ev; “OV”, “organization”, “business” or “truebiz” gives ov; anything else is dv.
• The term is always 1 year, which is the industry maximum.

That classification reads the description RackHelm stored for the eNom product when you picked it, so pick the certificate whose eNom description matches what you intend to sell.

The lifecycle #

SSL certificates run through the same provisioning pipeline as everything else. What differs is that ProvisionOrderItem takes an SSL branch and drives one step per scan tick rather than doing the whole job in a single run.

1. Purchase. When the order is placed the item is created with a provisioning status of awaiting_configuration — deliberately not pending, so the scanner cannot pick it up before a CSR exists. A certificate record is created alongside it at pending_configuration.
2. Configure. The customer opens the configure wizard, pastes a CSR, picks a validation method and a contact. The certificate moves to submitted and the item to pending.
3. Submit. The next scan dispatches the job. It buys the certificate order at eNom (once — a reissue keeps the existing id), records the provider’s certificate id, then sends the CSR and the chosen validation method. The certificate moves to awaiting_validation and the item is re-armed as pending.
4. Validate. The customer proves domain control: approving an email, publishing a CNAME, or serving a file.
5. Poll. Every scan tick the job asks eNom whether the certificate has issued. The attempt counter is reset on each in-flight tick so a long validation window does not inflate it.
6. Issue. On issuance the leaf certificate and CA bundle are stored, the expiry is copied to the order item, the item is marked provisioned and the customer is notified.

If eNom reports the order rejected, cancelled or failed, the item is marked failed with the reseller’s own status recorded against it. If the submit step fails, the item drops back to awaiting_configuration so the customer can correct their CSR and try again.

Certificate statuses #

Private keys are never involved #

The customer generates the key and CSR on their own server and pastes only the CSR. There is no private-key column on the certificate record and there never should be. The portal actively refuses a paste containing a BEGIN PRIVATE KEY block, and the stored CSR, certificate and CA bundle are excluded from normal serialisation so they cannot leak through an API response.

What the customer does #

Everything after purchase happens in the client area under SSL Certificates. See Configuring and downloading your SSL certificate for the customer-side walkthrough — the configure wizard, the three validation methods, reissuing and downloading.

Troubleshooting #