About Ordering and Management

When you place an order with Trustico® you are using one system, and when you manage the product you have purchased you are using another. This separation is deliberate, and it applies to everyone who deals with us, whether you are a customer, a partner, or an associate.

Understanding it removes most of the confusion that people experience when they move from our legacy platform to our regular platform, or when they look for an SSL Certificate in the wrong place. Our regular systems have been streamlined so that one consistent approach now serves every type of user, replacing the separate arrangements of the past.

The short version is straightforward. The ordering and billing system exists to place orders and handle payment. The product you purchase is managed in the tracking system, which is built specifically for that purpose. The two are connected for your convenience, but they remain separate systems doing separate jobs.

This page explains how each one works, how they relate to one another, and where each type of product is actually managed once you have paid for it.

The Ordering and Billing System

The ordering and billing system is where you purchase an SSL Certificate license, make payment, and review your history. It holds your list of orders and your invoices, and whenever you place a new order it records the details you provide on the billing page and produces an invoice based on that information.

The same ordering and billing system serves both customers and partners. Customers use it to purchase and pay in the usual way. Partners use the same system with different pricing structures, the ability to add additional users, and financial arrangements suited to operating at volume.

The underlying system is the same for everyone, which is part of how the regular platform has been streamlined.

The ordering and billing system also displays the SSL Certificate licenses that have been issued from your orders. Each one links directly through to the tracking system, so you can reach the management side with a single click rather than signing in to the tracking system manually. This is a convenience link, not a second copy of your SSL Certificate.

It is important to understand what this system does not do. It is not where you manage your SSL Certificate. It does not show you validation status, it does not perform reissues, and it does not hold the SSL Certificate files themselves.

Those tasks all belong to the tracking system, and the link from your order is simply the doorway to it.

This is also why placing a new order is always treated as a new and self-contained purchase. Each order stands on its own, which is why there is no such thing as a renewal in the traditional sense. A renewal has always been a fresh license purchased in place of an expiring one.

Note : The person who places and pays for an order does not have to be the same person who manages the SSL Certificate afterwards. A staff member might purchase a license one year and a different staff member the next, while the SSL Certificate itself is managed independently by whoever holds the relevant credential.

This division between buyer and manager is only possible because the two systems are kept apart. The next section explains why that separation matters in practice.

The Separation of Ordering and Management

The separation exists because purchasing a product and operating that product are two genuinely different activities, often performed by different people for different reasons. Billing relates to the account that made payment. Management relates to the SSL Certificate license itself and the website it secures.

Keeping these apart means that the billing account can change hands, move between staff, or even move between companies, without disturbing the ability to manage the SSL Certificate. It also means an SSL Certificate can be managed by a technical person who never needs access to invoices or payment details.

This design becomes clearer once you consider that what you purchase is a license, and the SSL Certificate is issued as a benefit of holding that license. The license, not the order, is the thing you manage.

Managing Traditional SSL Certificates

Traditional SSL Certificates and their licenses are managed in the tracking system. This is the dedicated management tool for any SSL Certificate that is not automated, and it has always been available to everyone, whether customer, partner, or associate. It works independently of the ordering and billing system.

Each license is issued a Certificate Authority (CA) Reference, which is the identifier used to locate that license in the tracking system. The tracking system is where you complete validation, perform a reissue, view your validity dates, and download your issued SSL Certificate.

For security reasons we do not publish the full set of credentials required to access a license. Anyone with the correct details for that license can manage it, regardless of which account placed the original order.

This is the reason your SSL Certificate is managed in the tracking system rather than the ordering account, and why it does not carry across when you move between platforms. The ordering account links you to it for convenience, but the management itself has always taken place in the tracking system.

Your SSL Certificates therefore remain fully accessible there at all times. Explore Our Tracking System 🔗

Important : Under current industry regulations an SSL Certificate must be reissued periodically throughout the license period, currently every 200 days. You complete each reissue yourself in the tracking system before the existing SSL Certificate expires. The ordering system plays no part in this process.

That covers traditional SSL Certificates. Certificate as a Service (CaaS) is managed in a different way again, which the next section describes.

Managing Certificate as a Service (CaaS)

Certificate as a Service (CaaS) works differently again. With Certificate as a Service (CaaS) there is no tracking system involved, because you manage the entire SSL Certificate lifecycle through your own Automated Certificate Management Environment (ACME) client.

You still purchase a license through the ordering system, and you still receive an invoice in the usual way. After that, instead of logging into the tracking system, you provide your External Account Binding (EAB) credentials and the relevant endpoint to your Automated Certificate Management Environment (ACME) client.

The client then requests, installs, and reissues your SSL Certificate automatically for as long as the license remains active.

So Certificate as a Service (CaaS) shifts the management away from any Trustico® interface entirely and into your own infrastructure. The ordering system handles the purchase, and your Automated Certificate Management Environment (ACME) client handles everything thereafter. Learn About Certificate as a Service (CaaS) 🔗

Taking Full Control of How Your Management Works

Some customers and partners want the systems to behave in a particular way, or to fit a workflow of their own design. If our standard tools do not work the way you would prefer, the answer is Certificate as a Service (CaaS), because it hands the entire management process to you.

With Certificate as a Service (CaaS), your choice of Automated Certificate Management Environment (ACME) client and the way you manage your SSL Certificates are entirely your own decisions. You select the client, you decide how it runs, and you build whatever surrounding process suits your environment.

There is no tracking system involved, because the Automated Certificate Management Environment (ACME) client is responsible for every aspect of issuance, installation, and reissue.

This is also the direction the industry is heading. Over time, customers and partners will be expected to adopt Certificate as a Service (CaaS), and at that point the management approach becomes a matter of your own design rather than something handled through our interfaces. The development and operational decisions remain yours throughout.

You do not need to wait for that point to arrive. Customers and partners are welcome to move to Certificate as a Service (CaaS) now and take that control today, provided the infrastructure to support it is in place.

Moving From the Legacy Platform

The same principles explain what happens when you move from our legacy platform to our regular platform. Orders and order history do not transfer across, because each order has always been a self-contained purchase rather than an ongoing record tied to your account.

This does not mean anything is lost. Any SSL Certificate you already hold continues to be managed in the tracking system using its Certificate Authority (CA) Reference, which works independently of whichever platform the order was placed on.

The move to a new ordering account does not affect your ability to manage existing SSL Certificates, because that has never been done through the ordering account.

Prepaid credit is handled separately. A legacy prepaid credit balance can be transferred to the regular platform on request. Learn About Our Legacy Platform Information 🔗

Knowing Which System to Use

If you need to purchase a new license, make payment, or find an invoice, you use the ordering and billing system on our website. If you need to validate, reissue, download, or check the validity dates of a traditional SSL Certificate, you use the tracking system with your Certificate Authority (CA) Reference.

If you are using Certificate as a Service (CaaS), you manage everything through your own Automated Certificate Management Environment (ACME) client and do not need either the tracking system or the ordering system once your license is active.

Recognizing which task belongs to which system removes nearly all the confusion that arises during the move to our regular platform. The ordering system is for buying. The management of what you bought happens elsewhere, and where it happens depends on the product you chose.

Whichever system you are using, the responsibility for keeping a website secured rests with the person operating it. This includes completing validation, performing each reissue on time, and keeping track of the relevant dates. Learn About Customer Responsibilities 🔗

Partners who manage SSL Certificates on behalf of their own customers carry the same responsibilities across every license they hold, often at greater scale. Find Out More About Partner Responsibilities 🔗

Most Popular Questions

Frequently asked questions covering how the Trustico® ordering and billing system works alongside the tracking system, where traditional SSL Certificates and Certificate as a Service (CaaS) are managed, what happens to orders and credit when moving from the legacy platform, and which system to use for each task.

The Difference Between the Ordering System and the Tracking System

The ordering and billing system is where you purchase a license, make payment, and view your orders and invoices. The tracking system is where you manage the SSL Certificate itself, including validation, reissue, and download. The two are connected for convenience but perform separate jobs.

Location of SSL Certificate Management After Purchase

Traditional SSL Certificates are managed in the tracking system, located using the Certificate Authority (CA) Reference issued with the license. Your ordering account displays the issued SSL Certificate licenses and links through to the tracking system, so you can reach the management side without signing in manually.

The Reason Orders Do Not Transfer Between Platforms

Each order has always been treated as a new and self-contained purchase rather than an ongoing record tied to your account. For this reason orders and order history do not transfer from the legacy platform to the regular platform, although any SSL Certificate you hold remains fully accessible in the tracking system.

Transferring Prepaid Credit From the Legacy Platform

A legacy prepaid credit balance can be transferred to the regular platform on request. Credit is handled separately from orders, which do not transfer across, so it is requested rather than carried over automatically.

Management of Certificate as a Service (CaaS)

Certificate as a Service (CaaS) does not use the tracking system. You manage the entire SSL Certificate lifecycle through your own Automated Certificate Management Environment (ACME) client, using your External Account Binding (EAB) credentials and the relevant endpoint. The client then requests, installs, and reissues your SSL Certificate automatically while the license remains active.

Using the Ordering System as Both a Customer and a Partner

The same ordering and billing system serves both customers and partners. Customers purchase and pay in the usual way, while partners use the same system with different pricing structures, additional users, and financial arrangements suited to operating at volume.

Eligibility to Manage an SSL Certificate License

The tracking system has always been available to customers, partners, and associates. The person who places and pays for an order does not have to be the same person who manages the SSL Certificate afterwards, as management depends on holding the correct details for that license rather than on the ordering account.

Taking Full Control of SSL Certificate Management

Customers and partners who want the management process to work a particular way should use Certificate as a Service (CaaS), which hands the entire process to them. The choice of Automated Certificate Management Environment (ACME) client and the way SSL Certificates are managed become their own decisions, with no tracking system involved. This option is available now, provided the supporting infrastructure is in place.

Knowing Which System to Use for a Task

Use the ordering and billing system to purchase a license, make payment, or find an invoice. Use the tracking system to validate, reissue, download, or check the validity dates of a traditional SSL Certificate. With Certificate as a Service (CaaS) you manage everything through your own Automated Certificate Management Environment (ACME) client.

Ask Trustico® Assistant

For Instant Answers - Start Here When You Have a Question or Need Help

Revocation Status Errors on a Valid SSL Certificate

Revocation Status Errors on a Valid SSL Certifi...

A revocation status error such as RevocationStatusUnknown can appear on a valid SSL Certificate. Learn how to confirm it is not revoked and what to do next.

Revocation Status Errors on a Valid SSL Certifi...

A revocation status error such as RevocationStatusUnknown can appear on a valid SSL Certificate. Learn how to confirm it is not revoked and what to do next.

Website Security Checks : Essential Steps to Protect Your Business Online

Website Security Checks : Essential Steps to Pr...

Keep your website secure with the SSL Certificate checks that matter most, from expiry and chain coverage to validation levels, issuance controls, and automation.

Website Security Checks : Essential Steps to Pr...

Keep your website secure with the SSL Certificate checks that matter most, from expiry and chain coverage to validation levels, issuance controls, and automation.

Installing an S/MIME E-Mail Certificate in Mozilla Thunderbird

Installing an S/MIME E-Mail Certificate in Mozi...

Import a PKCS12 E-Mail Certificate into Mozilla Thunderbird, assign it for signing and encryption, and exchange secured messages with any recipient.

Installing an S/MIME E-Mail Certificate in Mozi...

Import a PKCS12 E-Mail Certificate into Mozilla Thunderbird, assign it for signing and encryption, and exchange secured messages with any recipient.

Repackaging a PKCS12 File for macOS Keychain Compatibility

Repackaging a PKCS12 File for macOS Keychain Co...

Fix PKCS12 imports that macOS Keychain Access rejects despite a correct password by re-exporting the file with legacy compatible encryption.

Repackaging a PKCS12 File for macOS Keychain Co...

Fix PKCS12 imports that macOS Keychain Access rejects despite a correct password by re-exporting the file with legacy compatible encryption.

Fixing the IIS Binding Error - A Specified Logon Session Does Not Exist

Fixing the IIS Binding Error - A Specified Logo...

Resolve the IIS binding error stating a specified logon session does not exist by repairing the Private Key association or reimporting correctly.

Fixing the IIS Binding Error - A Specified Logo...

Resolve the IIS binding error stating a specified logon session does not exist by repairing the Private Key association or reimporting correctly.

Converting a Java Keystore to PKCS12 Format

Converting a Java Keystore to PKCS12 Format

Convert a legacy Java KeyStore (JKS) to PKCS12 with one keytool command, verify the contents, and extract PEM files for non-Java platforms when needed.

Converting a Java Keystore to PKCS12 Format

Convert a legacy Java KeyStore (JKS) to PKCS12 with one keytool command, verify the contents, and extract PEM files for non-Java platforms when needed.

1 / 6