HARICA announcement on Kiwifarms

2023-05-16 HARICA Support

HARICA supports the freedom of speech and expression, and the right for privacy which is why it invested time and effort to support and offer Onion certificates. This decision was welcomed by the Tor community.

HARICA does not check or censor website content protected by its certificates. However, every CA must follow a process to handle complaints from Third Parties and Law enforcement authorities associated with HARICA-issued certificates. If the complaint claims that a certificate is used in violation of the CP/CPS or the Greek/European Law, HARICA is obligated to investigate and check whether those claims are valid. HARICA takes complaints seriously and is especially sensitive to the “forbidden certificate use” clause in section 1.4.2 of its CP/CPS.

In the Kiwifarms case, we received such a complaint and proceeded with our investigation which led to reviewing existing online content. The following URLs were especially examined:

Without dismissing the seriousness of other concerning activities reported, HARICA was especially concerned with activities that might have led to suicides. A decision was made to revoke the certificate and an email was sent to the subscriber notifying that the certificate would be revoked in 3 days (on 2023-05-18), and that a new certificate should be obtained by another CA, which should be a trivial task to be completed within 3 days.

Minutes after sending that email, HARICA’s support team started receiving threat messages from unknown individuals, witnessing the behaviour described in the “Escalating threats” of https://blog.cloudflare.com/kiwifarms-blocked/. Support team members participating in the communications with the subscriber were personally targeted.

HARICA considers this behaviour unacceptable. As a non-profit CA, we try to support the Internet community with the best of our abilities and in a very challenging and demanding industry. If HARICA personnel continues to receive harassment for what is a CA decision (not a personal decision), we will have to revisit the risks associated with providing Onion certificates and possibly discontinue this service. Our personnel’s good health and safety is of upmost importance.

Among the numerous threat messages HARICA received, there was one case that followed the reporting procedure, was kind and polite, and highlighted the fact that there are currently only two publicly-trusted CAs that issue certificates for Onion domain names, and HARICA is one of them. This significantly minimizes the options of Subscribers with Onion domain names.

After considering that factor, HARICA decided to postpone the revocation action and wait for further investigations, if any, by the Greek Law enforcement authorities. The community should not mistakenly think that HARICA’s decision to postpone the revocation was due to the threats we received. We continue to reserve the right to revoke or not issue a replacement certificate, but we respect the fact that this particular subscriber has only one other option to obtain a certificate to protect their website. We hope more CAs will be able to support Onion certificates to alleviate that problem.

Adobe Acrobat settings for signature validation

2022-11-07 HARICA Support

Decision 2015/1506/EU pursuant to Regulation (EU) 910/2014 (also known as eIDAS) has defined a number of baseline profiles (e.g. PAdES, XAdES, etc.) to ensure that electronic signatures can be created and validated anywhere in Europe.

When a user performs a signing operation with Acrobat and tries to validate the signature at a later time using a signature validation software like DSS (Digital Signature Service) WebApp, either after the certificate’s expiration or revocation, the validation fails.

This happens because Acrobat’s default behavior is not conformant with the PAdES (PDF Advanced Electronic Signature) baseline profile. Its default settings do not include the mandatory “message-digest” attribute (and other signed attributes) which is enforced by the default DSS validation policy.

Acrobat offers a different signature option which does contain the “message-digest” attribute and passes validation by the DSS app successfully but needs the user to change the default settings of the application.

To do this, the user has to open Acrobat’s “Creation and Appearance Preferences” and choose CAdES-Equivalent as the Default Signing Format.

Finally, it is highly recommended that the checkbox “Include signature’s revocation status” is selected so the signature is LTV (Long Term Validation) enabled.

Signature Validation

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.

HARICA announcement on Kiwifarms

Adobe Acrobat settings for signature validation

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

Implementations that are considered problematic

Be proactive and prepare for speedy Certificate Replacement

Related Articles