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.
As described in https://www.us-cert.gov/ncas/alerts/AA19-024A the US Cybersecurity Agency warns about hackers trying to hijack DNS servers, and manipulating them to obtain SSL certificates for the hijacked domains.
This is a serious problem, since the vast majority of certificates, including CAcert’s “Class 1” certificates for non-assured members, are issued on “proof of DNS control” only.
“Extended Validation” certificates, which assure the real person or organisation controlling the domain, are not affected by this threat. But they are usually extremly expensive when requested from a commercial CA.
CAcert’s “Class 3” certificates for assured members, as well as CAcert’s Organisation Assurance are a (mostly) free alternative for those certificates, with an overall security level which is at least compareable, if not better!
Know whom to trust! Ask us on firstname.lastname@example.org if you want to know more details!
A fix for a long standing issue has recently been installed at the CAcert main server: Now finally it’s possible to create a client certificate from a Certificate Signing Request (CSR) in the user interface for Organisation (Org) Accounts.
For those who don’t have an idea what I am talking about, an Org Account is a user interface for administrators of companies and other organisations who got themselves assured with a CAcert Org Assurance.
Until recently, client certificates in an Org Account could only be created by using the browser feature to create a key pair and signing request in one go. This usually has the consequence that the administrator has access to the private key of the certificate, and has to send the private key and a password (hopefully secure) to the user the certificate is intended for.
While this is not that unusual in an organisation environment, it is not considered a clean solution.
The new feature to create a certificate from a CSR now allows much better solutions. Not only that the administrator does not need access to the end user’s private key at all, it’s now possible to create solutions where an organisation end user can create her own keys and CSR at the organisation’s website, while the administrator only confirms the validity of the request, gets the certificate from CAcert and posts it on a website for the user to download into her browser.
Especially in company settings CAcert certificates can productively used even though the root certificate is not included in browsers by default. Many companies use private CAs, for example to issue certificates which allow employees to securely log on to web applications. Now it’s possible to outsource the CA management to CAcert and just use an Org Account to issue certificates.
In my opinion CSR certificate creation is an important step to make CAcert certificates much more practical to use in company settings! Thanks to everyone involved in implementing this feature!
Wer es am 6. Januar nicht nach Amberg geschafft hat, der hat am Samstag eine weitere Chance!
Zusammen mit dem Bürgernetzverein Nürnberger Land veranstaltet CAcert ein Assurance Event in Winkelhaid. Es werden Organisation Assurer anwesend sein, aber auch wer sich persönlich assuren lassen oder Informationen zu CAcert erhalten will ist herzlich eingeladen.
Nähere Infos gibt es unter www.cacert-bayern.de
Those from Central Frankonia who did not make it to the event on Jan 6 in Amberg get a second chance this Saturday!
In cooperation with Bürgernetzverein Nürnberger Land CAcert is staging an Assurance Event in Winkelhaid near Nürnberg. There will be Organisation Assurers on site, but everyone interested in a personal Assurance or information about CAcert is welcome.
For more details see www.cacert-bayern.de
CAcert and secure-u e.V. are present at booths 244 and 251 in hall 7.2b during LinuxTag 2012, from March 23 to 26, in Berlin, Germany. For more details see the wiki page on LinuxTag2012.
Recently the hyphen rules in PracticeOnNames has been overworked and clarified.
Since this topic is surrounded by a great deal of confusion and unconfirmed rumors Assurers might have a look at it.
If you received email today stating that one or more of your certificates was revoked than this action was initiated by CAcert. See the announcement on the blog.
For more background information see the Arbitration page and Hanno Böck’s blog post.
A short summary, some certificates were found for private keys which could easily be cracked because of one of the following reasons:
- Their modulus size is small (y 1024 bits) and therefore quickly be “brute forced” with usual desktop computers.
- They use an small exponent which is vulnerable to well known cryptographic attacks
- They used a key generated by a buggy debian system (see Debian Vulnerability).
The CAcert web page has now been modified not to accept such weak keys for certificates in the future.
We wish to thank Hanno Böck for notifying us of this problem and giving us enough time to fix it before publishing it.
You may have received an automated mail by CAcert today or yesterday evening, stating that one or more of your certificates are unsafe and will be revoked soon.
I don’t want to go into more technical details before the relevant certificates have been revoked, if you received one of those mails some technical details are included there. Please do not use the listed certificates any more and replace them with newly issued ones as soon as possible.
If you tried to log in to CATS recently with a newly created certificate you probably failed. Especially when using a Class 3 certificate. Now I hope this bug is finally fixed.
Like usual for such bugs it was quite a trivial thing, for details compare CAcert/Education/CATS/login.php in svn with its previous version.
For analysis: certificates affected contained a serial number wich started with a non-digit character after stripping learing zeros. So Class 3 certificates with serial number bigger than 09:ff (issued since about half a year ago) and Class 1 certificates with serial greater than 09:ff:ff (issued since recently) have been affected.
I’m still waiting for the first explicit confirmation of someone now able to log in, but the analysis nicely fits the symtoms and the problem could be reproduced on the test system, so I hope we finally got it.