DV certificates for Onion websites

2021-04-26 TLS Certificates HARICA

UPDATE

Following the high demand for onion certificates, HARICA decided to extend the discount period till the end of August 2021.

Great news for Onion fans!

We are excited to announce that HARICA has started issuing Domain Validated (DV) certificates for v3 Onion websites.

HARICA is a Publicly Trusted Certification Authority (CA) that participates in all major Global “ROOT CA” Trust Programs (360, Adobe, Apple, Microsoft, Mozilla, Oracle), and operates as a “Trust Anchor” in widely used Application Software and Operating Systems (Adobe, Apple, Google, Microsoft, Mozilla, Linux).

Following this announcement, we offer a discount to all HARICA’s DV Certificates, which includes “onion”, “wildcard onion”, and other types of publicly trusted DV TLS Certificates, starting at 4.5€ per year till the end of June 2021 [EXTENDED to August 2021].

Get yours now at HARICA’s CertManager!

How to purchase your own DV certificate?

Create a HARICA account at HARICA’s CertManager.
Under the Certificates section on the left, choose Server Certificates and make a new request for your domain.
You have the Option to auto-generate your TLS CSR locally or manually submit one you have already prepared. Both RSA and ECDSA keys are supported.
To validate your Domain Name you have three (3) “general purpose” validation options:
1. Select a pre-defined email address of your domain to receive a confirmation email.
2. Upload a text file, provided by HARICA, to a specific location on your web server.
  - For v3 Onion domains only this “general purpose” validation option is allowed. There is also a special option available which uses the Tor hidden service ed25519 key to generate a special “Onion CSR” to prove you control the v3 Onion domain namespace, which allows you to obtain a wildcard Onion certificate *.<hidden service>.onion. This is currently the only secure option allowed to obtain a wildcard Onion certificate and HARICA has built and publicly disclosed the necessary code to support this method!
3. Add a DNS TXT record, provided by HARICA, to the selected authorization domain.
After the successful payment of your order, you can retrieve your certificate.

What is an “Onion Service”?

Onion services are anonymous network services that are accessed via the Tor Browser and the underlying Tor (a.k.a. “Onion”) network. Clients use Onion services via Onion domains that are only resolvable inside the Tor network. In contrast to conventional Internet services, Onion services are private and end-to-end encrypted, generally not indexed by search engines, and use self-certifying domain names that are long and difficult for humans to read. That is, you can offer a web server, SSH server, etc., without revealing the real IP address to its users.

Why would an Onion website need a TLS certificate?

There is a list of reasons as to why an Onion website would need a TLS certificate:

Mixing HTTP and HTTPS creates complex setups for websites.
To help the user verify that the Onion domain is indeed the site you are hosting (manual check at the certificate registration information).
Some services work with protocols, frameworks, and other infrastructure that have HTTPS connection as a requirement.
In case your web server and your Tor process are in different machines.

Our Success Story

2021-04-25 HARICA HARICA

Several years ago, an idea was born for an innovative (at the time) project based on the need for increased protection/security measures to encrypt communications over insecure networks, such as the Internet.

A team of Information and Communication Engineers from various Greek Universities and Research Centers collaborated and created a Public Key Infrastructure (PKI) that served and covered the security needs of the Academic and Research Institutions of Greece for SSL/TLS server and S/MIME certificates.

The project was successful and in the process our services were enriched, covering the growing needs of the Academic and Research Institutions. But we did not stop there. We wanted to offer our services outside the Academic/Research community.

Thus, we created the Certification Authority of the Hellenic Academic and Research Institutions (HARICA), which was initially supported by the National Research and Technology Network (GRnet) and then funded by the non-profit, civil company, Greek Universities Network (GUnet).

We started off by joining the Mozilla Root CA Program, which, even today, is the most strict and best supervised Global Certification Authority trust program, and gradually joined other major public trust programs.

After almost 15 years, HARICA is a Globally “Trusted Third Party” entity that simultaneously participates in all major Global “ROOT CA” Trust Programs (360, Adobe, Apple, Microsoft, Mozilla, Oracle) and operates as a “Trust Anchor” in International Software Companies and Operating Systems (Adobe, Apple, Google, Microsoft, Mozilla, Linux, Oracle Java).

Today HARICA’s services cover the full range of digital certificate needs and timestamps:

from the basic security level on SSL / TLS servers for individuals, businesses, and organizations
to the maximum level of security indication of large organizations (SSL EV, SSL QWAC, SSL QWAC-PSD2) fully meeting the requirements of Regulation (EU) 910/2014 (eIDAS) and Directive (EU) 2015/2366 on Payment Services (PSD2).

We provide products and services to individuals, companies and organizations:

S/MIME, certificates for digital signing and encrypting emails,
Code Signing, certificates used for digital software signing,
E-Signature, “Qualified” Electronic Signatures which replace the handwritten signatures, as well as “Advanced” Electronic Signatures and
E-Seal, electronic seals for Legal Entities, which, like its handwritten counterpart in the offline world, an electronic seal is a legal concept capturing the signatory’s intent to be bound by the terms of the signed document.

And we continue with the same enthusiasm, more structured and more experienced, improving and enriching our services offering the maximum security to our digital world.

Good practices for the use of HARICA's Publicly-Trusted Certificates

2020-11-30 HARICA Support

Dear HARICA subscribers,

We recently became aware that some elements of our Certification Policy/Certificate Practice Statement related to Certificate Revocation have not been so clearly communicated to our Subscribers. This article attempts to describe some recommended practices for Subscribers, and some bad practices (to be avoided) in order to improve the overall security of the use of Publicly-Trusted Digital Certificates for the benefit of Relying Parties worldwide.

Based on 4.9.1 Circumstances for revocation of HARICA’s Certificate Policy and Certification Practices Statement, by the time HARICA detects or receives a notification for a problematic certificate, must immediately inform the Subscriber. Under certain conditions, HARICA SHALL revoke a Subscriber Certificate within twenty four (24) hours to an extended five (5) days period, depending on the certificate type (TLS, S/MIME, eSignature, etc.) and the scale of the threat. For example, Certificates with incorrect values in their subject have a grace period of five (5) days but for Certificates that suffered a Key Compromise their revocation will be within twenty four (24) hours. Also, under certain conditions, HARICA SHALL revoke a Subordinate CA Certificate within seven (7) days in case of reasons described in HARICA’s Certificate Policy. A subset of these requirements are standardized Globally via the CA/Browser Forum’s Baseline Requirements, and all CAs issuing Publicly-Trusted TLS Certificates worldwide must adhere to these rules for Certificates in scope of this standard.

This means that ALL Subscribers that control HARICA Publicly-Trusted digital certificates must be prepared to ACT in an agile manner in order to replace existing Certificates within the above timeframes, once notified by HARICA.

Currently there is no requirement for Subscribers to inform or explain to HARICA in detail how they plan to use HARICA’s Certificates for Relying Parties to use. However, Subscribers must keep in mind the revocation requirements that they have agreed to via the Subscriber Agreement, and adjust their implementations/projects/solutions in such a way that their Certificates can be replaced in a timely manner within the specific timeframes, if needed.

Implementations that are considered problematic

HARICA contacted a number of Subscribers and organizations that developed solutions based on HARICA’s Certificates, and received some useful feedback. Although it is not our intention to criticise or comment about the design decisions of these use cases, it was obvious that the Subscribers/implementers’ intentions were to improve security (and in one sense this was accomplished by limiting the number of “allowed” Certificates) but at the same time there were unintended consequences (for example the difficulty in replacing certificates and adapting timely to industry or CA policy changes).

Certificate-based solutions that explicitly rely on information that is included in Issuing CA Certificate(s) is one of the popular reasons that cause difficulty for Subscribers to replace their Certificates. This practice is known as “certificate pinning”. Whether for TLS Client or Server Authentication, when an application “expects” some Certificates to be issued by specific Issuing CA Certificates, it is considered problematic. HARICA and other Certification Authorities are at liberty of introducing new Issuing CA Certificates and use those for issuing Subscriber Certificates, without prior alerting or contacting Subscribers or Relying Parties. Applications and solutions that are “pinned” on specific CA Certificates are likely to “break”, and will most probably need to be manually updated, therefore it is recommended that “certificate pinning” is avoided. Applications and solutions can always use information of the Subject Distinguished Name of end-entity Certificates to limit the Authentication scope.

Here is a list of applications/solutions that were reported to use certificate pinning:

user authentication for VPN services
user authentication on Web services
in Android apps
validation of digital signatures of specific organization(s)

There are also authentication schemes that rely on digital Certificates for authentication and signatures, mainly for server-to-server communication. The SAML2 authentication scheme is very popular especially in the Academic and Research sector (eduGAIN, InCommon Federation), where Identity Providers and Service Providers use Certificates to sign their Metadata and SAML2 assertions. Administrators of such services must be aware that these certificates don’t have to be Publicly-Trusted, and in fact they should either be self-signed or issued from a private PKI.

Be proactive and prepare for speedy Certificate Replacement

There are several reasons that Subscribers of Publicly Trusted Certificate need to be ready to quickly replace Certificates. Regardless of the use cases, there are always inherent risks in the technology used in Digital Certificates/Signatures. Policy requirements also change from time-to-time. For example, some existing methods for Domain and Identity Validation may become forbidden or deprecated because in the light of new evidence they are considered insecure. If these insecure methods were used for the issuance of certificates, it is possible that these certificates need to be tracked down and revoked.

Crypto and Policy agility are reasons that require CAs such as HARICA, Subscribers and Relying Parties to be in a position to adapt quickly to changes.

HARICA suggests the following good practices to TLS certificate subscribers:

subscribers can use ACME-based solutions for automatic certificate issuance/renewal. HARICA has an ACME beta solution for selected pre-validated Organizations to automatically issue TLS Certificates. This solution is planned to be offered to all Subscribers.
subscribers using TLS certificates in services/devices that implement old deprecated software/protocols (e.g. TLS 1.0 or 1.1 for IP camera software), it is recommended to use proxies which provide secure TLS connection termination using the latest protocol versions that also support ACME.

HARICA is prepared to respond to a demand for quick certificate replacement for non-TLS Certificates:

For S/MIME, Advanced eSignature/Seal and Code Signing (not EV), HARICA can re-key a certificate to issue an entirely new certificate, using some or all information submitted for an existing certificate and using a newly generated Key Pair.
For EV Code Signing and Qualified eSignature/Seal Certificates, in case the crypto-device or private key IS NOT compromised, HARICA can
- use the same Key-Pair and issue an entirely new certificate, using some or all information submitted for an existing certificate or
- generate a new Key Pair and re-key an existing certificate
- use an existing Key Pair that was generated during the provisioning process of a crypto-token device and issue a new certificate.
For Remote eSignature/Seal Certificate Subscribers, HARICA can use re-keying to issue an entirely new certificate, using some or all information submitted for an existing certificate and using a newly generated Key Pair.

Newer posts