Frequently asked questions

What is TinyCert?

TinyCert is a simple, free, PKI-as-a-service. It allows you to create your own CAs and certificates and serves as a central directory for your private and public keys, CSRs and certificates.

For what would I use TinyCert certificates?

Any place you would use (or should have used) self-signed certificates. Don't leave admin panels, such as phpMyAdmin, a CMS or a webmail install without some protection to keep your password from being intercepted. Use them to protect your test and development installations. Use them on your local POP or IMAP servers. Or use them to test your own code involving certificates.

For what purpose can TinyCert certificates be used?

Technically speaking, the keyUsage and extendedKeyUsage fields of your TinyCert certificates have been filled with very liberal values and are not marked critical. This means you can use TinyCert certificates for any purpose that does not strictly require a single-purpose certificate.

Why would I use TinyCert certificates?

TinyCert is more convenient than generating self-signed certificates manually. You also have the benefit of having an easy management interface for your certificates as well the option of being warned in advance when a certificate is about to expire. Commercially provided certificates can be expensive or limited in applicability. TinyCert certificates are available the instant you create the request. You also have access to your own CRL and can use TinyCert's OCSP server.

Should I use TinyCert certificates in production?

No. There is no technical reason you can't, but any regular user's browser will rightly put up a big fat warning message as they do not trust the root certificate of your TinyCert CAs. Instead, you should use certificates validated by a proper TTP. Some certificates are provided at very generous rates, and for certain uses StartSSL and Let's Encrypt offer them free of charge.

Is it safe?

TinyCert certificates are no more or less secure than self-signed certificates. Unless you install your own CA certificate in the browser or in the root certificate store of whatever other technology you use, they will complain about not being able to validate the certificates. This does not mean they are unsafe, just that they don't know to trust the certificates.

Technically speaking, the generated keypairs are 2048-bit RSA public and private keys. This is sufficiently strong for use on the web in the present day, certainly for the kind of testing purposes and private use for which TinyCert is intended.

What about my private keys?

Your certificate authorities' and certificates' private keys are generated on the TinyCert servers and stored in the database. They are kept encrypted using the passphrase you provided upon creating an account. Unless you request an unencrypted download and provide your passphrase, the private keys should never leave the server in unencrypted form. It is necessary to keep the CA private key on the server in order to be able to sign certificates you generate or regenerate CRLs when you revoke a certificate. A separate private key is encrypted using a passphrase generated by TinyCert to enable its use in automatically signing OCSP responses. There is no technical reason the private key for each individual signing request needs to be kept on the server, but this is done for convenience, as that is TinyCert's primary goal.

How secure is my passphrase?

Your connection to the TinyCert servers is encrypted and secured through HTTPS, so your passphrase should never go over the wire in plaintext form. On the server, it is kept encrypted with a key that is unique to each session and decrypted only as needed. In your local browser, the passphrase is kept in plaintext in the browser's sessionStorage and, if you elect to do so for convenience, also in localStorage. If you do not trust the computer you are using, do not allow the passphrase to be kept in localStorage (if you have inadvertently done so anyway, you may remove it from the profile page) and close the browser when you log out of TinyCert, to also clear it from sessionStorage.

What if I lose my passphrase?

Tough luck. If you forget your passphrase and have not kept it in your browser, we cannot help you recover your passphrase. You will be unable to create new certificate authorities, create certificate requests, sign certificates or download unencrypted private keys. Your only option is to delete every single one of your certificate authorities, and with them all certificates, and start anew. Either that, or download an encrypted key and attempt to crack the password from that, possibly through brute force. We can't help you with that.

What are the limits on TinyCert use?

You should not be using the TinyCert service to screw over good people (I suppose that precludes agencies such as the NSA from having permission to use it, though you would be more than welcome to use it against them). This is a moral obligation, not a legal one.

To ensure stability and availability of the service, and to prevent the use of bots, certain rate limits are in place on creating accounts, CAs and certificates. Under ordinary circumstances, no user should run into these. If you do, please wait a minute or two and try again.

How long are TinyCert certificates valid?

Individual certificates are automatically signed to be valid for 365 days. After that, the certificate is considered expired. As the request is saved in your account, you may then simply reissue the certificate to get a new one that is valid for another year. If you have enabled notification of impending expiration, you should receive up to 3 e-mail reminders, a month, a week and a day prior to expiration.

The CA root certificates are valid for 10 years from the moment you create them.

Can I revoke or reinstate TinyCert certificates?

Yes, you can do so from the dashboard. If you use a CRL, you can download one for each of your CAs from there as well. The OCSP responder and the publically accessible CRL should update instantly, though the results may be cached by your browser or other client. Note that even if you reinstate a certificate from "revoked" status to "hold" or "good", most clients that have seen the "revoked" status will no longer accept the certificate. You may want to reissue it instead.

Can I delete certificates?

Not individually, though you can revoke or reissue them, which you would typically do once they are close to expiring. The only way to actually delete certificates is to delete the entire CA, see below.

Can I delete my certificate authorities?

Yes. Doing so deletes all associated certificate and request data too. Any certificates you have in use when the parent CA is deleted are essentially useless from that point on.

Can I delete my account?

If you want to permanently delete your account, please delete all the certificate authorities in it before requesting deletion.

Which hashing algorithm should I pick?

It depends on what you want to support. SHA-1 is presently the most commonly used algorithm but, like MD5 before it, it is being gradually phased out by browser developers because of weaknesses in the algorithm. As of 2017, SHA-1 certificates will not be accepted by most browsers and warnings will pop up long before then. SHA-256 signed certificates are more secure, but not accepted by older browsers and operating systems, such as Windows XP (pre-SP3) and Android 2.3.

For maximum compatibility at this time, select SHA-1. For best security, select SHA-256. All certificates you generate through TinyCert inherit the hashing algorithm from the associated CA.

Can I create wildcard domain certificates?

Yes. You can enter *.example.com as the Common Name on a certificate. In that case, you'd probably also want to add both DNS Names *.example.com and example.com as Subject Alternate Names.

What are "Subject Alternate Names"?

A certificate can apply to more than one thing. Many webservers are configured to listed to both the root domain and the www subdomain. That way, visitors will have the content served regardless of whether they go to http://example.com or to http://www.example.com/. A HTTPS client would consider these distinct and a certificate created for one would not work on the other. You could install two separate certificates, each with their own keys, but it is more convenient to use one single certificate and keypair. In this case, you would put www.example.com as the Common Name, as usual, but also add both it and the root domain as alternate DNS names. Do this by typing www.example.com in the "New value" field, then click "DNS Name". Then do the same for example.com.

I have a FQDN in the Common Name, should I also add it as an alternate name?

If you have more names than that single FQDN, you should also add that FQDN from the Common Name to the alternate names. Browsers can choose to look at either one of the common name and alternate names, but need not look at both. Therefore, if you have SANs, your Common Name should be duplicated into the list.

What are Quick Access URLs and are they safe?

It is not uncommmon to access the TinyCert website from a different computer than the one on which you need the certificates. Command line HTTP clients such as curl or wget are not really suited for logging in to TinyCert and getting the appropriate files. To save you the hassle of having to download them and then transfer them onto the target system yourself, you may generate Quick Access URLs. These are generated on request and you can simply pass them on to your command line HTTP client and download the selected data directly.

You should take care not to let Quick Access URLs fall into the wrong hands (emailing them would not be a safe thing to do) as no authentication is required other than having the URL. Quick Access URLs expire 1 hour after you generate them.

Can I create Extended Validation certificates?

No. There are strict issuance requirements and CAs must pass audit reviews before they can issue EV certificates. This is outside the scope of TinyCert.

Can I create a CSR using other methods and upload it for signing?

No. There is no technical reason this should not be possible, but it does not fit in the TinyCert philosophy of convenient management through the TinyCert website.

Is there an API to manage my TinyCert certificates?

Yes. We have an HTTP API.

How do I get my browser to accept TinyCert certificates?

Either by adding an exception for each individual certificate (cumbersome, and requires manual action when the certificate expires), or by installing the CA root certificate into your browser. Check out the help page for more details.

Is TinyCert open source?

No. While TinyCert is free as in gratis, parts of the code powering the website and various assets are under a proprietary license. Users have expressed a desire to run their own private instances of TinyCert and we are actively exploring the possibility of releasing a stand-alone package for local installs as fully open source software over the course of 2015.

Client libraries for the API are (or will be) made available under the Simplified BSD license.

Why is it free?

Why not? Providing this service is not costing us anything extra beyond the investment of our time and the hosting that we were already paying for. If you find TinyCert useful and wish to donate, that would be appreciated anyway.