According to CA/B Forum Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates and HARICA’s Certificate Policy and Certification Practices Statement for the Hellenic Academic and Research Institutions Public Key Infrastructure (CP/CPS), starting June 1, 2023, it will be mandatory for Code Signing Certificates to have their private keys stored in hardware devices such as tokens or Hardware Security Modules (HSMs) with at least security standard of FIPS 140-2 level 2 or Common Criteria EAL 4, following the existing requirements for Extended Validation Code Signing Certificates.

This new policy optimizes the protection of private keys and upgrades the security of Code Signing Certificates.

What are the policy changes for Code Signing certificates?

Starting June 1, 2023, HARICA will exclusively issue Code Signing Certificates to hardware devices (tokens).

If subscribers prefer to use their own device, this must meet the minimum security standards of FIPS 140-2 level or Common Criteria EAL 4+.

To request for a new Code Signing Certificate, subscribers can submit their requests through our portal cm.harica.gr. Once the certificate is issued, if needed, we will send a token to the subscriber’s preferred address via courier.

We would like to emphasize that HARICA maintains consistent pricing for Code Signing Certificates. This means that the cost of acquiring a Code Signing Certificate and the hardware device remains unchanged.

What will happen to Code Signing Certificates issued prior to June 1, 2023?

Code Signing Certificates issued prior to June 1, 2023, will remain valid until their expiration date. Subscribers of these certificates do not need to take any action. The changes introduced only to Code Signing Certificates that will be issued on or after June 1, 2023.

How will HARICA’s Code Signing Certificates be renewed after June 1, 2023?

Code Signing Certificates that have been purchased in the years 2022 and 2023 for more than three (3) years and their renewal occurs after June 1, 2023, HARICA will provide the necessary token at no additional cost to the subscribers.

Do you have additional questions or concerns?

If you have questions or need more information, please contact the HARICA support at support@harica.gr.

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.

• https://blog.torproject.org/tls-certificate-for-onion-site/
• https://twitter.com/torproject/status/1374814543252049920?lang=el
• https://newsletter.torproject.org/archive/2021-03-31-onion-tls-petition-ban-biometric-surveillance/
• https://community.torproject.org/onion-services/advanced/https/
• https://www.facebook.com/TorProject/photos/a.10151472966454951/10161197452869951/?type=3

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:

• https://en.wikipedia.org/wiki/Kiwi_Farms
• https://blog.cloudflare.com/kiwifarms-blocked/

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.

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.

Sky is the limit

All of us involved in HARICA’s activities as a “Qualified Trust Service Provider (QTSP)” share a common philosophy that can be summed up in the words of Henry Ford: “If everyone moves forward in sync, then success comes naturally”.

A few years ago, we decided to expand our activities beyond the Academic and Research boundaries. Since then, our projects have exceeded our initial expectations and we feel deeply honored to be trusted by high-profile leading organizations, institutions, public and private, in Greece, in Europe and in the rest of the world.

The e-platform gov.gr of the Ministry of Digital Governance issues millions of digital documents, including Covid Vaccination Certificates, e-declarations and authorizations with HARICA’s e-Seal as well as the Central Electronic Document Management System (mindigital-shde.gr) issuing Remote Qualified Electronic Signatures for Public Administration to civil servants for signing legally binding documents as defined in the eIDAS regulation. The e-platform diavgeia.gov.gr uses HARICA certificates to formally announce governmental and administrative decisions and resolutions. The e-National Social Security Fund (e-Efka) uses HARICA’s e-Seal and Server Certificates. EYATH, (Thessaloniki Water Supply and Sewerage Company) trusted us for the Qualified eSignatures and the Email Certificates (S/MIME) of its employees.

The Council of State, Administrative Regions of Greece, the Ministry of Labour of Cyprus, Municipalities, Professional Chambers, the Supreme Attorneys Associations, Notary Associations as well as European Organizations such as EU Agency for the Cooperation of Energy Regulators (ACER), CEDEFOP and private companies such as BETA CAE, KLEEMANN and SPACE HELLAS are a few of HARICA’s high-profile Subscribers that have entrusted us for adding security to their digital services.

Big Social and News networks such as Facebook use HARICA’s wildcard certificates, providing encrypted communications and data security to billions of their users.

In the demanding field of electronic payments, we issue PSD2 digital certificates in accordance with the European Payment Services Directive 2 (PSD2) and Regulation 910/2014 (eIDAS), providing the highest level of security. This is why banking institutions such as ALPHA BANK, OPTIMA BANK and Third-party Payment Provider (TPP) companies such as CARDLINK, MIA PAGO Ltd, Perlas Finance, and Money Capp trust HARICA to secure their electronic transactions.

Our accomplishments do not make us complacent, they motivate us to continue our efforts with even more enthusiasm, but also with more knowledge and experience to improve and expand HARICA’s trusted services, because for us “only sky is the limit”.

Thank you!

We are pleased to announce that on the 1st of June 2022, HARICA will switch the issuance of SSL/TLS certificates to its 2021 Root TLS Certification Authorities.

Both HARICA TLS RSA Root CA 2021 and HARICA TLS ECC Root CA 2021 are already pre-installed on Windows operating systems as well on macOS 12 providing the necessary trust anchor for Google Chrome, Microsoft Edge and other popular Internet Browsers. In addition, Mozilla Firefox has updated its Certificate Store with HARICA’s new RootsCAs.

For older operating systems and browsers, HARICA issued two additional cross-certificates to chain the 2021 hierarchy with the older 2015 one for increased ubiquity.

Both HARICA TLS Root 2021 ECC and RSA cross-certificates can be used by our subscribers in their certificate chain files to cover the majority of browsers regardless of their version.

UPDATE

Following the high demand for eSignatures, HARICA decided to extend the discount period till the end of February 2022.

Why use a Qualified Electronic Signature?

Use the electronic signature to digitally sign documents (PDF) and ensure the authenticity and integrity of their content. Since legally binding (cross-border in the European Union) you can use the electronic signature in:

• Contracts (sales, employment, lease, insurance, etc.)
• Transactions (e-commerce, online banking, tenders, etc.)
• Administrative procedures (requests to public sectors, etc.)

Offer information

The offer is valid from 1/12/2021 until 31/01/2022 and is addressed to professionals, e.g. engineers, lawyers, notaries, etc. The offer is about the purchase of a Remote Qualified Electronic Signature with 1-4 years validity period.

Get the offer

The interested party must contact support@harica.gr stating his/her business details. Then, he/she will receive a 50% discount coupon, which he/she can use when completing the order.

A solution for Financial Institutions and Payment Service Providers

Are you a Financial Institution? Is your business dealing with electronic payment and open banking? Are you looking for security, privacy, and reliability for your electronic services across EU borders?

According to the EU directive 2015/2366 (PSD2), you need a Qualified Web Authentication Certificate (QWAC) and/or Qualified Electronic Seal Certificate (QSealC).

PSD2 at a glance

Payment Service Directive 2 (PSD2) is the second revised directive of an existing Payment Service Directive from 2007. The Regulatory Technical Standards (RTS) of PSD2 requires strong customer authentication using common and secure open standards of communication between all parties involved, to support Open Banking.

As from September of 2019 all EU financial institutions ensure that Payment Service Providers (PSPs) or Third-Party Providers (TPPs) can access their customer account data by using secure website certificates (QWAC).

All regulated entities that use APIs in order to provide account information services and/or to initiate payments, must be registered to a National Competent Authority (NCA) and need a Qualified Website (QWAC) and/or Qualified Seal (QSeal) Certificate to access the financial institution’s account data.

HARICA’s PSD2 Qualified Certificates

HARICA is a public Qualified Trust Service Provider (QTSP) per Regulation (EU) 910/2014 (eIDAS) and issues Qualified Certificates (QWACs and QSealCs) as specified in the PSD2 Regulatory Technical Standards (RTS):

• SSL QWAC-PSD2 (Qualified Web Authentication Certificate – PSD2):
  • SSL/TLS Server Certificate that includes one or more FQDNs,
  • official identity information of the Legal Entity that owns/controls the domain(s)
• eSeal – PSD2 (Qualified Certificate for Electronic Seals – PSD2):
  • Electronic Seal Certificate that includes information of the associated organization
  • official identity information for the Legal Entity

Get your QWAC-PSD2 starting at 400€ per year

and/or QSealC-PSD2 starting at 450€ per year

Need more information about our services?

Send us your request at support@harica.gr or use our contact form at https://www.harica.gr/en/Contact/GetHarica !

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.

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.

Related Articles

• https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
• https://www.nginx.com/blog/nginx-ssl/
• https://www.haproxy.com/blog/haproxy-ssl-termination/
• https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222
• https://technical.edugain.org/