CAcert’s European Bank Accounts

3 Replies

deutsch:
Ab sofort können Zahlungen aus dem SEPA-Raum* auf das europäische Bankkonto von CAcert überwiesen werden. Für Spenden können Sie weiterhin das Bankkonto von Secure-U in Deutschland verwenden (so vermeiden wir, dass Geld sinnlos hin- und her geschoben wird, da Secure-U für uns die Server mietet); für Mitgliederbeiträge sollte jedoch das untenstehende Bankkonto in der Schweiz verwendet werden, da nur dann der Mitgliederbeitrag dem Mitglied zugeordnet werden kann. Sie finden untenstehend Name, Postleitzahl/Ort, IBAN-Kontonummer und Bank:

CAcert Inc
7514 Sils im Engadin
Schweiz
IBAN: CH02 0077 4010 3947 4420 0
Graubündner Kantonalbank, Chur
Clearing 774
BIC (SWIFT) GRKBCH2270A

Payments from these countries (SEPA) are particularly easy.

italiano:
A partire da ora, i pagamenti dall’area SEPA* possono essere trasferiti sul conto bancario europeo di CAcert. Per le donazioni prego di utilizzare il conto bancario Secure-U in Germania; tuttavia, per le quote associative, si deve utilizzare il conto bancario in Svizzera sotto indicato, poiché solo in tal caso la quota associativa può essere assegnata al socio. Qui di seguito trovate nome, numero postale/località, numero di conto IBAN e banca:

CAcert Inc
7514 Siglio in Engadina
Svizzera
IBAN: CH02 0077 4010 3947 4420 0
Banca Cantonale Grigione, Coira
Clearing 774
BIC (SWIFT) GRKBCH2270A

Rumantsch:
CAcert Inc
7514 Segl Maria
Svizra
IBAN: CH02 0077 4010 3947 4420 0
Banca Chantunala Grischuna, Cuira
Clearing 774
BIC (SWIFT) GRKBCH2270A

English:
As of now, payments from the SEPA area* can be transferred to CAcert’s European bank account. For donations, the Secure-U bank account in Germany can still be used (to avoid that money is transfered twice on the same account); however, for membership fees, the bank account in Switzerland listed below should be used, as only then the membership fee can be assigned to the member. Below you will find name, postcode/town, IBAN account number and bank:

The leading bank in southeastern Switzerland.

CAcert Inc
7514 Sils/Segl Maria
IBAN: CH02 0077 4010 3947 4420 0
Grisons Cantonal Bank, Coire
Clearing 774
BIC (SWIFT) GRKBCH2270A

The bank is rated AA/stable by Standard&Poor. It also has a state guarantee from the state (canton) of Grisons (one of Switzerland’s 26 provinces).

Français:
Dès à présent, les paiements provenant de l’espace SEPA* peuvent être transférés sur le compte bancaire européen de CAcert. Pour les dons, continuez d’utliser le compte bancaire Secure-U en Allemagne; en revanche, pour les cotisations, il convient d’utiliser le compte bancaire en Suisse indiqué ci-dessous, car ce n’est qu’alors que la cotisation peut être attribuée au membre. Vous trouverez ci-dessous le nom, le code postal/le lieu, le numéro de compte IBAN et la banque :

CAcert Inc
7514 Segl Maria
IBAN: CH02 0077 4010 3947 4420 0
Banque Cantonale des Grisons, Coire
Clearing 774
BIC (SWIFT) GRKBCH2270A

* SEPA Area: all 27 countries of the European Union, furthermore: Guadeloupe, French Guyana, Martinique, Réunion, Mayotte, Saint-Pierre, Miquelon, Canary Islands, Azores, Madeira, Ceuta, Melilla, United Kingdom, Gibraltar, Isle of Man, Jersey, Guernsey, Switzerland, Liechtenstein, Norway, Iceland, Monaco, San Marino, Holy Seed, Croatia, Andorra.

Browser manufacturers shorten certificate lifetime to one year

4 Replies

From September onwards, HTTPS certificates may only be issued for a maximum of one year.

Reading time: 1 min.

The maximum validity of certificates for proof of identity on the web will be further reduced – in the next step to one year. Although a vote on this issue in the CA/Browser Forum failed in September due to resistance from the certification authorities, it is still being discussed. But in March Apple came forward and declared that Safari will only accept certificates issued after September 1, 2020 if they are not valid for more than one year.

Now Mozilla and Google are following suit and creating facts. In the past, terms of 5 years were not unusual. Currently, certificates may still be issued for 2 years (more precisely: 825 days — i.e. plus some grace period). With the renewed tightening, Chrome, for example, delivers an ERR_CERT_VALIDITY_TOO_LONG if a certificate was issued after September 1, 2020 and is valid for more than 398 days.

Revocation broken

The main reason for the constant shortening of the certificate lifetime is the fact that there is no generally functioning revocation mechanism by which a certificate could be revoked. Revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) have proven to be unsuitable and are now switched off by default.

The browser manufacturers still maintain their own internal revocation lists, which they can use to react to acute incidents. But this is a quasi manual procedure that can only cover significant problem cases. Ultimately, the browser manufacturers are now focusing on damage limitation: if, for example, the secret key of a certificate is stolen, an expiration date that is approaching as soon as possible should solve the problem.

No need for action for users

Lets Encrypt, which meanwhile dominates the market, is the pioneer and only issues certificates for 3 months anyway. Renewal is then automated via ACME. According to Mozilla, however, the other certification authorities have also agreed to only issue certificates for 398 days from September 1. In view of the demonstration of power of the browser manufacturers, they probably don’t have much choice.

As a web site operator, you don’t have to do anything else – even if you still have a certificate with a longer validity in operation. The new rule only applies to certificates issued after September 1, 2020.

Les fabricants de navigateurs ramènent la durée de vie des certificats à un an

Leave a reply

À partir de septembre, les certificats HTTPS ne peuvent être délivrés que pour une durée maximale d’un an.

Temps de lecture: 1 min.

La validité maximale des certificats pour la preuve d’identité sur le Web est encore réduite – dans l’étape suivante à un an. Un vote à ce sujet au sein du CA/Browser Forum en septembre a échoué en raison de la résistance des autorités de certification. Mais en mars, Apple s’est manifesté et a déclaré que Safari n’acceptera les certificats émis après le 1er septembre 2020 que s’ils ne sont pas valables plus d’un an.

Aujourd’hui, Mozilla et Google suivent le mouvement et créent des faits. Dans le passé, des mandats de 5 ans n’étaient pas inhabituels. Actuellement, les certificats peuvent encore être délivrés pour 2 ans (plus précisément : 825 jours — c’est-à-dire plus un certain délai de grâce). Avec le nouveau resserrement, Chrome, par exemple, délivre un ERR_CERT_VALIDITY_TOO_LONG si un certificat a été délivré après le 1er septembre 2020 et est valable plus de 398 jours.

Révocation cassée

La principale raison de la réduction constante de la durée de vie des certificats est le fait qu’il n’existe pas de mécanisme de révocation généralement opérationnel permettant de révoquer un certificat. Les listes de révocation (CRL) et le protocole OCSP (Online Certificate Status Protocol) se sont révélés inadaptés et sont désormais désactivés par défaut.

Les fabricants de navigateurs tiennent toujours leurs propres listes de révocation internes, qu’ils peuvent utiliser pour réagir à des incidents graves. Mais il s’agit d’une procédure quasi manuelle qui ne peut couvrir que les cas problématiques importants. En fin de compte, les fabricants de navigateurs se concentrent maintenant sur la limitation des dommages: si, par exemple, la clé secrète d’un certificat est volée, une date d’expiration qui approche le plus tôt possible devrait résoudre le problème.

Pas de nécessité d’action pour les utilisateurs

Lets Encrypt, qui domine entre-temps le marché, est le pionnier et ne délivre de toute façon des certificats que pour 3 mois. Le renouvellement est ensuite automatisé via ACME. Selon Mozilla, cependant, les autres autorités de certification ont également accepté de ne délivrer des certificats que pour 398 jours à partir du 1er septembre. Compte tenu de la démonstration de puissance des fabricants de navigateurs, ils n’ont probablement pas beaucoup de choix.

En tant qu’exploitant de site web, vous n’avez rien d’autre à faire – même si vous disposez toujours d’un certificat d’une durée de validité plus longue en service. La nouvelle règle ne s’applique qu’aux certificats délivrés après le 1er septembre 2020.

Recent infrastructure updates

2 Replies

In the past few weeks Dirk Astrath and me upgraded some of our infrastructure systems to Debian Buster and implemented some performance improvements.

The blog system you are just visiting is one of these systems. We also upgraded the wiki system and finished the setup of the new community Webmail system.

The old staff list and community email password reset pages have been replaced with a modern system that is now available at https://selfservice.cacert.org/.

The git code hosting system at https://git.cacert.org/ has been upgraded to Debian Buster too and has been switched from gitweb to cgit for the git web frontend for much better performance. The old gitweb URLs are automatically redirected to the new cgit URLs. This change has the positive side effect that you can now use git clone directly using the https-URLs of the git repositories.

In the background we added Puppet configuration management for the above mentioned systems and replaced the aged nrpe-based monitoring with Icinga 2 agents.

We setup a new community start page at https://community.cacert.org/ that leads you to resources that we think is relevant for our community members.

Signer is working again

5 Replies

Today we were able to investigate the signer machine at the datacenter.

As previously assumed, the signer machine was powered off. It was not possible to power it on again, so either both PSUs or other components died.

As we ordered a replacement-machine of the same type we were able to use the existing harddrives to power up the signer again.

Currently the signer is catching up, which will take some hours. As soon as your certificate was processed, you’ll get an email from our server.

The certificate of www.cacert.org is in the queue (together with your certificates and revocations), so we need to wait until it’s ready. It will get updated as soon as possible.

Update 2020-05-05: All pending certificates requests are processed now, new requests should now processed on the fly again.

Dirk Astrath
CAcert critical admin

Technical problems with signer machine

6 Replies

We have a problem with the signer machine, certificates are currently not created.

There is no way to access the signer machine via internet, to make sure that the machine can not be hacked, so a personal visit to the data center will be necessary to check the machine and get it running again.

Sadly the current Covid-19 pandemy makes travelling to the data center very difficult, so we have no way to fix this problem soon! I’m afraid that it may take several weeks till we get access to the machine and find out the reason for this problem.

Update: Currently we hope that we will be able to make the visit to the data center around easter weekend.

Of course this depends on other developments we have no influence on. For example further restrictions to travelling or intra-EU border crossing may prevent this visit.

Update: In case you can’t access https://www.cacert.org or https://secure.cacert.org currently due to the expired certificate, you may reset the HSTS-status in Chrome:

Open chrome://net-internals/#hsts and delete www.cacert.org and secure.cacert.org settings there. Accessing www.cacert.org will then give you a warning about the expired certificate, but you’ll then be able to continue.

Update: A visit at the datacenter is planned for 2020-05-04 to enable the signer again as well as additional administration tasks on other hardware.

Update: All services are normal again, see new blog post.

Change in the Committee

Leave a reply

Frédéric Grither from France has resigned as treasurer of CAcert Inc. However, he will continue to offer his expertise and experience as a member of the CAcert finance team. On 13 February 2020, the Committee (Board) was able to fill the vacancy by electing Christophe Meesters from Belgium to the Committee. Christophe is a proven financial expert.

Bret Watson from Australia is now also supporting us in the finance team, particularly with regard to Australian issues. The board is very grateful to know that the finances of our fellowship are in good hands and that we have managed to spread the work over several shoulders.

Soziale Netzwerke im Kinderzimmer

Leave a reply

Soziale Netzwerke sind schon längst im Kinderzimmer angekommen – immer jüngere Kinder nutzen sie. Influencer auf Plattformen wie Instagram oder YouTube begleiten unsere Kinder im Alltag. Da stellt sich einmal mehr, wie Eltern oder auch ältere Geschwister damit umgehen sollen.

Anlässlich des heutigen Safer Internet Day (SID 2020) fordert Youtuber Robin Blase mehr Medienkompetenz. CAcert erarbeitet zur Zeit entsprechendes Unterrichtsmaterial.

European Data Protection Day and Data Privacy Day

Leave a reply

Today we celebrate the European Data Protection Day founded by the Council of Europe (CoE) and the Data Privacy Day in the United States and Canada. We want to raise awareness of data protection and the right to privacy. At CAcert we provide you digital certificates with which you can protect your private data for example by encrypting your mails. To use them you must offer CAcert some of your data, but in order to protect your privacy, we ask you for fewest data possible and we have strict rules how to handle personal data.

Feel secured with CAcert and choose “I have nothing to hide … except for my privacy.”

dirk astrath

2020-01-22

Since yesterday evening the main webserver of CAcert is currently not available.

We’re working hard in the background to get it up and running again.

Update:

According to the logfiles the server crashed at (or shortly after) Jan 21 18:07:39

The machine is up again after a hardware restart since: Jan 23 10:55:17

(Software-Restarts of the sun-server did not help yesterday …)

The root-cause-analysis is yet to be done (and will be done later the day).

Update2:

A detailed investigation of our logfiles did NOT show any intrusion attack. We were not able to find any details, why the hardware-server stopped responding.

Sorry for any inconvenience.

dirk astrath

CAcert Crtitical Admin