View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1544 [Main CAcert Website] account administration block always 2022-10-19 14:17 2022-11-21 15:24
Reporter: bdmc Platform: Default  
Assigned To: bdmc OS: any  
Priority: immediate OS Version: any  
Status: ready to deploy Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: Ted
Test Instructions:
Summary: Unable to delete users in support console due to date calculation
Description: Support is unable to delete user records due to a miss-calculation of dates.
Tags: support
Steps To Reproduce: This bug does only occur on MariaDB, not on MySQL, so it can currently only be provoked on test3.cacert.org:

- Find an account which has at least one certificate attached, but all attached certificates are expired more than 90 days ago. Since it looks like accounts can be "deleted" multiple times, try searching for "a20221021.1.1%".
- Using a user with support access, search for the account in "System Admin -> Find User"
- Click on the "Delete Account" link
- Enter a (syntactically correct) new user name. If you did search for a20221021.1.1, use the same name.
- Klick "OK" ==> the system reports "The CCA retention time for at least one certificate is not over. Can't continue."

Note: This procedure won't provoke the bug if the calculation "NOW()-90*86400" accidentially results in a "convertable" integer. I don't think that this is possible, but have not verified this...
Additional Information:
System Description Default profile.
Attached Files: bug-1544.patch (2,039 bytes) 2022-10-23 12:51
https://bugs.cacert.org/file_download.php?file_id=521&type=bug
Notes
(0006138)
Ted   
2022-10-19 14:22   
Is there a bit more info?
What is the error message, what is the mis-calculation?
(0006139)
bdmc   
2022-10-19 15:46   
As per conversation with Dirk, modified notary.inc.php to use AddDate function instead of manual date calculation.


See Pull Request https://github.com/CAcertOrg/cacert-devel/pull/37
(0006140)
bdmc   
2022-10-19 15:48   
Ted, as Dirk reported to me, in the current database, the date calculation fails and users can not be removed because that date calculation, in the current database, results in comparing a date with a number, rather than a date with a date.
(0006141)
bdmc   
2022-10-19 15:50   
I see other places in the code where the "now()" function is used in various ways, so could have similar issues, but this fix was to address this specific issue.
(0006142)
Ted   
2022-10-19 18:59   
Can I get a bit more information about this bug, to have some documentation? What exactly did happen?

Was this problem found in a code review or did it happen on the support console? If the latter, what was the error message? Or what was the situation when it was decided that it was a bug? Was it possible to provoke the situation on the test system?

I see your proposed code changes and I have some guesses, but I'd really like to get a more detailed description to verify that I'm on the right track!
(0006143)
egal   
2022-10-19 19:34   
i got the information from support/ales, that members can't be deleted despite all certificates had been expired (or revoked) more than 100 days ago.
while tracking it down i found a date-calculation in notary.inc.php
on a local machine (using mysql-version we have on test-server) i created a table with a field containing a date in past and used the calculation we're using in the php-script
on my own servers (mariadb) i tried the same, but got different results compared to mysql

unfortunately the testserver we have are based on mysql using debian8 instead of mariadb on debian11

there is the plan to create new test-servers from scratch with a proper setup and deployment-system using the same setup as we have on webdb1 (sun1) now, but unfortunately these servers are not yet set up ... ;-(
(0006144)
egal   
2022-10-19 19:42   
checking the code linked in https://bugs.cacert.org/view.php?id=1544#c6139 i spot an issue:

now()-90*86400 will get a date in the past (substraction)
adddate (now(),90) will get a date in future (addition)

as we need the date in the past (as it should not be possible to delete an user of there had been valid certificates within the last 90 days according to our rules) this needs to be fixed
(0006145)
alkas   
2022-10-19 19:47   
The error message with no number simply says, that the account cannot be deleted, as any user's cert did not reach the time period since expired/ or is not revoked. That time period is not specified in the message, according to the Dirk's Telegram message it should be 90 days. But there are users with last expired cert in 2012 and so.
(0006146)
alkas   
2022-10-19 19:50   
Accounts of some users, who never issued a cert, can be deleted with no problems.
(0006147)
Ted   
2022-10-19 19:54   
@alkas, so you tried to klick on "Delete Account" after searching an account in the System Admin application, correct?

I cannot provoke the problem on the testsystem https://test.cacert.org/account.php, but from everything I read here the analysis of @egal and @bdmc sounds plausible.
(0006148)
alkas   
2022-10-19 20:06   
1. copy username & ticket #
2. System Admin, search account
3. Enter ticket #, go
4. click Delete Acc, fill the serial # from Wiki page (a20141024.1), click Yes
5. if the user has any cert issued, error message appears.
(0006149)
bdmc   
2022-10-19 20:55   
Sorry about that. I was trying to be too quick. I will fix and re-submit.
(0006150)
Ted   
2022-10-19 20:58   
@bdmc no need for another patch request because I'll have to create the patch manually anyway (or can anyone tell me how to convert the patch request into a new branch bug-1544 in github?)...
(0006151)
bdmc   
2022-10-19 21:05   
(Last edited: 2022-10-19 21:07)
Patch Request updated.

I was working in branch bug-1544 in GitHub, if that helps.
(0006152)
Ted   
2022-10-19 22:07   
(Last edited: 2022-10-19 22:08)
Though I still don't know exactly what happened, the old code will surely not do what it should do (find all certificates which expired later then 90 days before now).

So, I reviewed commit 626cb03b65e939db95fa62af1f04906cbfa6f27a of branch bug-1544 versus 05b03d6cb5196f296abde465e3d2ecf1395bc132 od release branch.

The review is PASSED. Though I'm not 100% sure that it fixes the current problem, it does the calculation that is expected of it.
(0006153)
Ted   
2022-10-19 22:11   
I want to do a quick test on the testserver, to make sure that no typos were overlooked, but this will have to wait till tomorrow.
(0006154)
Ted   
2022-10-20 20:59   
I was now able to verify the problem on test3 with MariaDB 10.1.48.

Addition of an integer to a datetime results in the datetime being cast to an integer. For example '2022-10-19 12:34:56' is converted into 20.221.019.123.456, then the integer is added or substracted.

When comparing a datetime to an integer, mysql seems to convert the datetime column into an integer. Though the result is not correct, the error is not obvious.

MariaDB, on the other hand, seems to convert the integer into a datetime. If the integer cannot be converted, for example because the final 2 digits are bigger than 60, this conversion results in '0000-00-00 00:00:00'.

So now I'm quite sure that the fix proposed by @bdmc will fix the issue.
(0006155)
Ted   
2022-10-20 21:05   
Now I was also able to provoke the problem on https://test3.cacert.org:14943/account.php
(0006156)
Ted   
2022-10-20 22:16   
I made a very rough patch on test3, and I cannot provoke the problem anymore.

Unless anyone else sees any problem I'll try to prepare the patch tomorrow evening. Or on Saturday...
(0006157)
Ted   
2022-10-23 12:51   
Patch request sent to critical admins
(0006158)
alkas   
2022-11-21 15:24   
Is the Ted's previously mentioned patch "bug-1544" in place? I tested it yesterday, unfortunately the same error message appeared!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1417 [Main CAcert Website] certificate issuing major always 2016-10-03 17:31 2022-10-16 14:51
Reporter: Wiesshund Platform: PC Windows 10, IE11 Chrome Firef  
Assigned To: Ted OS: Windows 10 Pro 64bit, Ubuntu  
Priority: urgent OS Version: Current  
Status: confirmed Product Version: 2015 Q3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Unable to generate client certificate
Description: Unable to generate client certificate
Clicking generate keypair in browser results in the error

"I didn't receive a valid Certificate Request, please try a different browser."

This happens in IE11, Edge, Chrome current version, and Firefox current version.
Tags: browser, certificates, html
Steps To Reproduce: log in to cacert.org
click client certificate
click new
check off wanted email address
click agree to terms
click generate keypair within browser

Immediately receive error "I didn't receive a valid Certificate Request, please try a different browser."
Same error occurs in IE11 Edge Chrome and Firefox

Additional Information: CACerts.org is added as trusted site
TLS and SSL are enabled
Tested running Trusted Sites on low security setting in IE
Tried on both 32 and 64 bit versions of all broswers
System Description Production version of the CAcert website
Attached Files: keygen.png (22,621 bytes) 2018-01-07 09:00
https://bugs.cacert.org/file_download.php?file_id=422&type=bug
New Client Certificate.png (175,952 bytes) 2019-09-10 20:50
https://bugs.cacert.org/file_download.php?file_id=467&type=bug
certificate-creation-sequence.png (51,389 bytes) 2021-06-26 21:46
https://bugs.cacert.org/file_download.php?file_id=505&type=bug
certificate-creation-sequence-2.png (75,271 bytes) 2021-06-27 08:33
https://bugs.cacert.org/file_download.php?file_id=506&type=bug
certificate-creation-sequence.txt (1,571 bytes) 2021-06-27 08:33
https://bugs.cacert.org/file_download.php?file_id=507&type=bug
Notes
(0005529)
L10N   
2016-12-24 19:29   
The same bug happend to me to with
- Chromium 55 on Ubuntu 16.04
- Vivaldi 1.6 64 Bit on Ubuntu 16.04
- Edge on Windows 10

But I could create a new certificate with
- Firefox 50.1 on Ubuntu 16.04
(0005534)
L10N   
2016-12-28 10:43   
Some other checks to create new certificates:
it does NOT work with
- Edge 38 on Windows 10
- Opera 42 on Windows 10
- Vivaldi 1.4 on Windows 10

it works still with
- Firefox 48.0 on Windows 10
(0005569)
L10N   
2018-01-07 08:41   
I filed a bug at Chromium and at Vivaldi a few days ago. Following the answer from Chromium:

    Issue 799246 in chromium: Cannot create a certificate with cacert.org
Absender
    Von: asa… via monorail

Updates:
Components: Internals>Network>Certificate
Status: WontFix

Comment 0000003 on issue 799246 by asanka@chromium.org: Cannot create a certificate with cacert.org
https://bugs.chromium.org/p/chromium/issues/detail?id=799246#c3

This site is using the <keygen> element to generate a keypair. This feature is deprecated. See https://www.chromestatus.com/features/5716060992962560

Attachments:
Screen Shot 2018-01-05 at 4.44.07 PM.png 22.1 KB

--
You received this message because:
1. You reported this issue
(0005570)
L10N   
2018-01-07 08:43   
"Since Chrome 49, <keygen>'s default behaviour has been to return the empty string, unless a permission was granted to this page. Removed in Chrome 57."

"IE/Edge do not support <keygen> and have not indicated public signals to support <keygen>. Firefox already gates <keygen> behind a user gesture, but is publicly supportive of removing it. Safari ships <keygen> and has not expressed public views regarding its continued support."

source: https://www.chromestatus.com/features/5716060992962560
(0005571)
L10N   
2018-01-07 09:03   
Further information at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen

"Deprecated
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Avoid using it and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time."
(0005572)
L10N   
2018-01-07 09:49   
Alternatives to <keygen>:
https://w3ctag.github.io/client-certificates/
https://w3ctag.github.io/client-certificates/

Other discussions about alternatives:
https://stackoverflow.com/questions/36350954/html-keygen-alternative-generating-key-pair-in-browser
https://security.stackexchange.com/questions/106257/alternatives-to-htmls-deprecated-keygen-for-client-certs

Further readings:
https://lists.w3.org/Archives/Public/www-tag/2015Sep/0000.html
https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/pX5NbX0Xack
(0005574)
gukk_devel   
2018-01-14 15:03   
https://developer.mozilla.org/de/docs/Web/HTML/Element/keygen
https://productforums.google.com/forum/#%21topic/chrome/FGU6TvIgPY0;context-place=forum/chrome
https://support.comodo.com/index.php?/Knowledgebase/Article/View/475/0/which-browser-can-i-use-to-signup-for-a-email-certificate
(0005575)
bjantzen   
2018-01-14 17:40   
Generating keys still works for me with
Firefox 57.0.4 (64-Bit, Linux) installed in openSUSE Leap 42.3.
(0005576)
L10N   
2018-02-10 10:05   
On Fri, 2 Feb 2018 10:29:41 +1100, Peter Yuill <peter AT NO SPAM c.o.> wrote at CAcert Board List:
I went through the process of generating keys and CSR in openssl then
submitting CSR through the advanced section of “New Certificate” and it
worked perfectly for me (using current Firefox). I have to say it is not a
simple solution and it certainly requires a much higher level of technical
skill than the browser solution, but it does work.

I did some research on possible tools to simplify the process and I have a
proposal. As far as I can see the browser route is dead, so we need to look
elsewhere. I am looking at the possibility of a desktop app that would
generate keys and CSR then connect to the cacert.org <http://cacert.org/>
site through a screen scrape library to submit the CSR and store the
certificate back in a local keystone. The one extra step required is to
import the certificate into browsers/mail clients, which should not be
difficult for most people. I am starting work on a cross-platform proof of
concept which I hope to be able to demonstrate in a few weeks.
(0005585)
dops   
2018-04-18 21:23   
"The browser route is dead" - indeed, so solutions running natively on the platforms are necessary.
A technical discussion thread was started here:
https://lists.cacert.org/wws/arc/cacert-devel/2018-04/msg00000.html

Supporting many platforms can be challenging. Because a simple solution is better than none, I'd prefer to have console-based scripts using on-board tools such as openssl (usually available for UNIX-style systems) or certreq (on standard Windows since many years - Vista?) as a baseline. Automating the CAcert certificate request page is not essential for the simple tool variant, where a graphical, more powerful and comfortable variant can complement it and doesn't need to cover platforms on an equal level or have the same robustness.

For UNIX-style systems I created a shell/openssl based solution as proof-of-concept here:
http://70t.de/download/ , file with pattern cacert_client_certificate_<date>.tar.xz (at time of writing cacert_client_certificate_2018-04-11.tar.xz )

Read more on cacert-devel starting here
https://lists.cacert.org/wws/arc/cacert-devel/2018-04/msg00000.html
(0005587)
RogerCPao   
2018-05-02 23:32   
I tried out cacert_client_certificate_2018-04-09.tar.xz. Thanks for creating it. I have a few suggestions/remarks about it.


A)

Multiple inputs of a passphrase are required:
  1. Unlock the key (from the file generated in the first task)
    -----
  2. Set a passphrase for the new certifcate file
  3. Repeat (confirm) the passphrase from 2. above
Input area (sequence of 3 passphrases): [1. Unlock key password]
Enter Export Password: [2. passphrase for new cert]
Verifying - Enter Export Password: [3. repeat 0000002]

The three numbered items should be explicitly numbered and named in each of the prompts that come after. The first prompt of "Input area (sequence of 3 passphrases): " does not indicate that you are supposed to type on the "passphrase to protect the generated key" when generating the RSA private/public key pair.


B)

If ready, press enter to open the certificate with the browser for import.

[
In the case of Firefox 59.0.2 (64-bit), Ubuntu 16.04.4,
a dialog box will ask
What should Firefox do with this file?
(*) Open with [View file (default]
( ) Save File
[ ] Do this automatically for files like this from now on.
[OK]
Questions about passphrase and labels eventually displays
the certificate details but is not imported. I had to go to Firefox's Certificate Manager and
manually [Import...] the newly created new_certificate_$USER.pfx file.
You will need to unlock the .pfx file with the
"Enter Export Password: [2. passphrase for new cert]" from above.
]
(0005588)
RogerCPao   
2018-05-02 23:35   
Oops. That note should have gone to the mailing list where cacert_client_certificate_2018-04-09.tar.xz was posted. There is no edit/delete.
(0005828)
vmbentley   
2019-09-07 18:22   
It is nearly three years since this issue was raised. Has there been no viable alternative process found for generating client certificates without the deprecated keygen tag?

Would it be possible for someone to write a HowTo guide for manually performing the process on the command line using OpenSSL and putting a corresponding CSR submission form on the website for the server side part of the process.
(0005829)
BarryN   
2019-09-07 19:09   
Could something like this be used?

https://pkijs.org/
(0005830)
BarryN   
2019-09-07 19:14   
Here is an example that uses that code:

https://csrhelp.peculiarventures.com/
(0005831)
BarryN   
2019-09-07 19:18   
Here's another option:

https://www.php.net/manual/en/function.openssl-csr-new.php
(0005833)
Ted   
2019-09-08 12:16   
(Last edited: 2019-09-08 12:16)
As a reply to https://bugs.cacert.org/view.php?id=1417#c5828 there indeed is a workaround for this problem.

If you click the "show advanced options" checkbox you can provide a manually created CSR, which makes the keygen tag obsolete. But the process in not really easy or user friendly. See https://wiki.cacert.org/FAQ/CSR as a starting point if you want to try that way.

(0005834)
Ted   
2019-09-08 12:51   
(Last edited: 2019-09-08 12:52)
I had a (very short!) look at the proposals of BarryN.

https://www.php.net/manual/en/function.openssl-csr-new.php will probably not help us, because this is code that runs on the server. It would not be appropriate for our standards to create a keypair on the server and then send it to the browser, because of the additional risk of compromising the key on the server or during transfer. BTW, this is the reason why CSRs have been invented.

https://pkijs.org/ looks more promising to me. As the provided example shows, the library seems to be able to create a keypair and a corresponding CSR locally in the Browser. If the library uses the key storage of the browser for key generation and therefor does not have access to the private key itself, this may be a valid replacement of the keygen tag, since this is exactly what the tag does.

But, first of all, this assumtion has to be verified by a code review. If the library creates the private key "itself", therefor having access to it, this also imposes the risk that the private key is compromised during the creation process.

Another downer is the sentence "Safari, Edge, and IE do not have complete, or correct implementations of Web Crypto.", which once again leaves a significant portion of the browser market uncovered...

Nevertheless, if there's anyone who would like to give it a try it may be worth to do more research in this direction.

(0005835)
vmbentley   
2019-09-08 13:38   
The 'downer sentence' was from 2015. Almost all browsers are supported now. To see what is and isn't supported visit https://caniuse.com/#feat=cryptography
(0005837)
BarryN   
2019-09-09 16:36   
I thought the java script solution might be the better one. I have tested a few browsers and the basic functionality seems to work. According to the chart the current version of IE, Edge, Chrome, Firefox and Safari all have at least basic support.
(0005857)
Ted   
2020-01-06 11:22   
From a mail on the Support mailing list:

Hallo zusammen,

seht Euch mal die Library PKI.js an. Das ist ein Werkzeugkasten in
Javascript für alle Operationen auf X.509 Zertifikaten. Damit kann man
im Browser erzeugen:

* Keypair
* PKCS#10 CSR
* PKCS#12 File

Das PKCS#12 File muss der User dann nur noch in den Browser importieren.
PKI.js kann deutlich mehr, als das alte <keygen>, damit kann man z.B.
auch EC Keys erzeugen.
(0005895)
L10N   
2020-06-27 13:28   
What's the state of play?
What happened to the app from Peter Y?
What happened to the proof of concept from dops?
What about pkijs.org?
What happened to the Java Script solution?
What about the library PKI.js?

As a technical layman, I do not really understand it. The approaches sounded promising. Were they pursued further?
(0005911)
Felixishim   
2020-10-21 12:27   
same here as L10N here and hoping some type of solution would be soon proposed.
(0005912)
Ted   
2020-10-29 21:31   
(Last edited: 2020-10-29 22:37)
Looking into https://pkijs.org/ once more.

It seems possible to create a web page which could replace the key creation with openssl where openssl is not readily available (like on Windows):
- Create a key pair with the generateKey API
- Create a PKCS10 CSR with a user provided data for CommonName and SubjectAltName using the CertificationRequest class of PKIJS
- Show the PEM encoded request to the user for Copy/Paste
- The user must then paste the CSR into the CAcert web page, and use Copy/Paste to copy the created certificate into the PKIJS-based website
- The PKIJS based website combines key and certificate in a PKCS#12 (*.pfx) structure which can be downloaded by the user

This PKCS#12 structure can be imported into Mozilla's certificate database or into the windows certificate storage.

Of course this also has the potential to be integrated in the CAcert web page, which could eliminate the Copy/Paste operations, but I'd consider that as the second step.

The main problem I see is that the creating script knows the created private key and could easily compromise it (intentionally or unintentionally). This is essentially the same as in an openssl based script, but since the script is loaded on demand from some webserver, as well as several libraries, the potential of fishing-like abuse is IMHO considerably greater...

Nevertheless it could be an easier-to-use variant for Windows users.
(0005913)
dops   
2020-10-29 22:26   
Regarding download: Search engines present solutions for locally creating files for "download". The first link looks like a clean and modern solution, which is also later mentioned behind the 2nd link with a longer history:
https://shinglyu.com/web/2019/02/09/js_download_as_file.html
https://stackoverflow.com/questions/3665115/how-to-create-a-file-in-memory-for-user-to-download-but-not-through-server

So should be promising that all private key related operations can be done locally in the browser.
(0005920)
Ted   
2020-11-29 19:16   
I've tried a "proof of concept" implementation at https://secure.convey.de/publish/ted/TestPKI.html

The PKCS#12 file created there can be parsed by OpenSSL, but neither the Windows Certificate Storage nor Thunderbird/Firefox are able to use it for import... :-(
Probably there's still some research necessary about the details of PKCS#12 creation...
(0005921)
jandd   
2020-11-30 00:01   
I implemented a GPL-2+ licensed proof of concept based on the Forge JavaScript PKI library (https://github.com/digitalbazaar/forge) with a small Go backend using an example openssl CA. The PoC can be found at https://git.dittberner.info/jan/browser_csr_generation and can be built/run using the instructions in the README.md file contained in that repository.

I could import PKCS#12 files created by this PoC project successfully in Firefox and the GNOME keystore (Seahorse).
(0006017)
tim.devries   
2021-06-22 23:02   
My code should be verifiably correct according to outside sources. It should work Everywhere.

Period.

Next.

So try: https://tecreations.ca/java/downloads/release/SecurityTool_User

So that would be: org.cacert.SecurityTool_User IF you understand Java.

Launch it, try, see what happens.

So Far, CACert, doesn't recognize or won't accept, a CSR. The Key has nothing to do with it.


CSR == CERT. Yes/No? What do you think?

If they can sign, if not, I can.


They'd have to 3rd party, accepted 3rd Party Signature.

So, If you need, I will. Accept, Verify, Sign.

All data reference points.

Name:

Locale:

Special Identifiers, #codeSigning, #clientAuth, #serverAuth, #SSO, if you want.
(0006018)
tim.devries   
2021-06-22 23:47   
Ok, hang on, will post when tested: Copy/Paste Link:

https://tecreations.ca/java/downloads/release/signed-cacert.org.jar

GenerateKey, Copy CSR, View Clipboard.

Try That.....
(0006019)
tim.devries   
2021-06-22 23:56   
Oh, there's some kind of problem....

I'll try to repost when I have an answer.

You should be able to:
Download
Unpack to <User.Home>restarted-1\....
Launch org.cacert\SystemTool_User

Generate Key, Copy CSR, View Clipboard....

It doesn't really matter, CA Cert Won't Sign. I can sign, but do you trust me???

I mean c'mon, get real.


Tim
(0006020)
tim.devries   
2021-06-23 00:03   
You may generate valid PEM CSR by using tecreations.ca/java/downloads/release/signed-cacert.org.jar

And Then Clicking "Generate Key", this will create a new private key.

Click "Get CSR" that will copy the CSR to the clipboard, based on your current DistinguishedName parameters. This is to identify you apart from everyone else.

Click "View Clipboard": This should show your current selection, ie, your CSR.

This is what you should paste to CACert.

It currently is NOT WORKING CORRECTLY.

Options are available to VERIFY YOUR SITUATION.

Tim
(0006021)
Ted   
2021-06-26 21:45   
(Last edited: 2021-06-26 21:45)
Hello @jandd,

I got your proof of concept from 0001417:0005921 running on windows, with some troubles, only to find out that this was probably not necessary at all. ;-)

What I found out matches quite well with your flow diagram, so I guess I got the right idea... I can confirm that the created PKCS#12 files can be imported into the windows certificate storage. Probably the details of the DN in the CSR have to be polished a bit, but as a proof of concept this is indeed quite good.

Concerning integration of the backend into the existing infrastruction, I'd propose to install the backend service on the CAcert webserver, so it can have access to the main database, and maybe the filesystem.

In this setup the backend can, after verifying the user's password or certificate, write the CSR into the "right" database table (DomainCerts for server certs or EmailCerts for client certs). So it will be sent to the signer, who in turn stores the created certificate in the database. Then the backend can read the cert from the database and return it to the browser, where the frontend can continue to create the PKCS#12 file.

From my gut feeling I'd advise against using a web socket connection to push the "certificate ready" notification to the browser. It is much easier for the user to evaluate (with the browser's network analysis tool) what's going on, and which data is sent to CAcert, if only POST and GET are used. So this should make it easier to review the process and get confidence that indeed no private keys or other private things are sent to the server. ==> The browser should poll in intervals to check if the certificate is already available. Note that the backend might even give some hint on the "expected time of arrival", based on the number of open requests in the signer's queue...

Apache itself might be configured use rewrite to forward requests for a specific path to the backend, so the backend might be accessible by something like https://www.cacert.org/certapi/...

This way we could probably create a very quick and clean integration of your PoC into the existing infrastructure, without writing a single line of PHP code. The certificates created with the backend would show up normally in the user's account page and could be managed, revoked and renewed using the existing user interface. On the other hand, if we decide that the backend has any problems we could easily turn off the whole thing by removing the rewrite rule, and everything would be as before.

And, as a bonus, the backend may be the foundation for full grown support of the ACME protocol, to completely automate issuing of server certificates, like it is provided by let's encrypt. So you might notice that I really like this! :-)

The main problem I have is, that currently I have no idea on who could review the backend. I had no contact with Go yet, so at the moment I cannot do reviews in good consciousness. I don't know about Dirk (or maybe Gero), but I've not yet heard them talking about Go... Nevertheless I'd propose to implement the backend on the testserver as soon as possible. While it usually needs some time, learning a new programming language is not something completely new to me ...
(0006022)
Ted   
2021-06-26 21:46   
(0006023)
alkas   
2021-06-27 06:45   
NOTE: Your chart is valid, till the browser used is capable to create a CSR. AFAIK only the Basilisk, Palemoon, and Seamonkey browsers are able to do it nowadays (2021-06). Did you mean to use some plug-in module(s)?
(0006024)
jandd   
2021-06-27 08:07   
@alkas my code uses the https://github.com/digitalbazaar/forge JavaScript library. It is not dependent on support for the <keygen> HTML tag or some other proprietary extension. The JavaScript code runs completely in the browser. The code has been tested in Firefox (ESR and latest) and Chromium and should work in Edge, Opera and others if their JavaScript/ECMAScript is relatively modern (read they did not live under a rock for the last 5 years).
(0006025)
jandd   
2021-06-27 08:33   
I attach an updated sequence diagram (+ PlantUML source) that has numbered steps and more details.

The following steps will utilize the Forge library: 011, 012, 022, 026. The other steps in the Browser will either use plain HTML or custom JavaScript code

After step 014 the signer client will attempt to get the certificate signed. On success it will be written to the database and returned in step 018.

If the API endpoint is separated from the regular PHP application we need a way to identify the user in step 013 to be able to validate the certificate request. A possible solution could be a random token (similar to a CSRF token) that is sent to the user in step 006, stored in the database and sent in step 013 (i.e. as Bearer token in an Authorization header).
(0006026)
jandd   
2021-06-27 08:50   
We could use signed (HMAC) JWTs for authentication and would not need to store the token in the database then (in step 006). There are PHP libraries for creating JWTs and there are Go libraries for parsing and validating JWTs. A validity period for the JWT could be calculated from the issue timestamp (JWT payload field "iat").
(0006027)
alkas   
2021-06-27 10:03   
@jandd my knowledge gaps filled, One question: Private keys are encrypted in PKCS#12. You use the password from Step 9 to encrypt PK in PKCS at Step 22, right? - I can also offer testing on about 5-7 more browsers under Windows 10 and Linux Ubuntu, if you need it.
(0006028)
Ted   
2021-06-27 10:23   
I found the setup of the backend a bit tricky, so I'd really love to set it up on the testserver. That way it would be easy to let loose the whole zoo of browsers on the code.

First step: Setup as is, on its own TCP port, with its own CA keys and OpenSSL creating the certificates
The next steps would then be integration into the web page and access to the database to create certs with the (test-)signer...

@jandd, is the current testserver enough up to date to install all the necessary dependencies (Node.js, Go, whatever else is missing)? Should I try to do the installation or will you do it yourself? We'll need an additional TCP port in the firewall, I guess that's something you must do yourself anyway?
(0006029)
jandd   
2021-06-27 10:44   
The test server is running Debian 8.11 (which is EOL), the nodejs version in Debian 8 is ancient (0.10.29~dfsg-2) as is the go version (1.3.3-1+deb8u2).

I think it would be better to have a separate container to build the actual release packages/binaries and only use the compiled result on the test server. Maybe we could do this on https://jenkins.cacert.org/ as we do for other Go builds.

We need a proper deployment process for other reasons so this might be a good reason to start developing it :-)
(0006030)
jandd   
2021-06-27 10:48   
(Last edited: 2021-06-27 10:49)
Here is a small example for generating a valid JWT for a user in PHP (can be checked via https://jwt.io/):

<?php
require 'vendor/autoload.php';

use Lcobucci\JWT\Configuration;
use Lcobucci\JWT\Signer\Hmac\Sha256;
use Lcobucci\JWT\Signer\Key\InMemory;

$configuration = Configuration::forSymmetricSigner(
    new Sha256(),
    InMemory::base64Encoded('qRxCOLBj+12J+gDvVLOOBJv7xvyKt1nV1KadkjeGcn8=')
);

$now = new DateTimeImmutable();
$token = $configuration->builder()
        ->issuedby('https://www.cacert.org')
        ->permittedFor('https://certapi.cacert.org')
        ->issuedAt($now)
        ->canOnlyBeUsedAfter($now->modify('+15 minute'))
        ->withClaim('uid', 'db952e7f-4393-4ecd-9673-207d061e212e')
        ->getToken($configuration->signer(), $configuration->signingKey());


all variables that are hardcoded in the example should come from configuration or the database (in case of the uid claim).

I successfully checked the code in a Debian 8 Docker container to see if it will work with PHP 5.
(0006031)
Ted   
2021-06-27 10:51   
We still have the "new" testsystem at test3.cacert.org. Maybe we update that to a recent Debian version and try to get the PHP code of the main website running there? Or just use it for the backend and indeed add some (PHP?) api to the "old" testsystem?

I agree to developing a deployment process, but hopefully that should not block testing/developing for too long...
(0006032)
jandd   
2021-06-27 10:58   
@alkas yes the private key is encrypted in https://git.dittberner.info/jan/browser_csr_generation/src/branch/master/src/index.html#L150 (it uses 3DES because AES is not supported properly in many Applications/Systems yet). I agree with @Ted that we should have a deployment on the test server, because a local setup requires a lot of developer tooling.

@Ted do you need a development container (from my point of view we should separate development from testing) in CAcert infrastructure or will it be sufficient to have automatic processes that build and deploy the binaries / JavaScript code to a test system when there is a change in a git repository/branch?
(0006033)
jandd   
2021-06-27 11:05   
The new testsystem (test3) uses PHP 7. Our PHP code base is not compatible with that without merging at least https://github.com/CAcertOrg/cacert-devel/pull/21 into an integration branch and testing it extensively.

If we choose to go the PHP 7 route we should put our main activities there. This would also allow us to upgrade the production system to a supported OS.

If PHP 7 is not a high priority I think we should build the binaries / JavaScript on a different container and either copy it manually to the current test server or build some deployment automation to deploy it automatically from Jenkins. This is actually not too much work. I think a few lines of Jenkins DSL and Ansible should get this done.

Should I go the PHP 7 route first or should I start with a proposal for the deployment automation?
(0006131)
jandd   
2022-07-28 17:07   
My proof of concept implementation from https://bugs.cacert.org/view.php?id=1417#c5921 is now available at https://code.cacert.org/jandd/poc-browser-csr-generation
(0006137)
NoSubstitute   
2022-10-16 14:51   
Today I tested the poc-browser-csr-generation and it created a certificate with the name I provided, encrypted with the password I provided.
Certificate chain (Example Root CA, Example Email CA, Kim Nilsson) was included in the P12, and all certificates installed nicely in Windows 10.

I ran the POC in WSL Debian 11.5 on my Windows 10 Pro, 21H2, 19044.2130, Windows Feature Experience Pack 120.2212.4180.0.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1543 [Main CAcert Website] account administration minor N/A 2022-07-06 20:47 2022-10-11 18:43
Reporter: egal Platform: Main CAcert Website  
Assigned To: egal OS: N/A  
Priority: normal OS Version: stable  
Status: fix available Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions: database needs to be modified on testserver to reproduce this issue ... and to see, if a fix works
Summary: email-adresses without member-id need to be deleted
Description: As long as the "strict" setting was active on webdb1 there were 28 email-addresses, which do not belong to any account in email-table.

Normally emails of members, which are not verified, are deleted after 24 hours (according to our text) or 48 hours (according to our coding).

As the memid is empty, these email-addresses would stay in email-table forever ... blocking these email-addresses (users) to join cacert.
Tags: login error, migration, webdb
Steps To Reproduce: none (as strict-mode was switched off for database)
Additional Information: According to our coding a "memid=0" should not be possible ...

... but in strict mode for mariadb it was not possible to create an entry in user-table ... resulting in "id=0". This value was added to email-table:

> select * from email where memid=0 order by id desc;
+--------+-------+--------------------------------+---------------------+---------------------+---------------------+------+----------+
| id | memid | email | created | modified | deleted | hash | attempts |
+--------+-------+--------------------------------+---------------------+---------------------+---------------------+------+----------+
| 567890 | 0 | email@domain.tld | 2022-07-04 12:34:56 | 2022-07-04 12:34:56 | 0000-00-00 00:00:00 | | 2 |
(...)

(Obviously it's not a productive record above ... ;-) )

If a valid user-record could be created, the field memid is the reference to the user-record and therefore not 0.
System Description Production version of the CAcert website
Attached Files:
Notes
(0006121)
egal   
2022-07-06 20:51   
(Last edited: 2022-10-11 18:43)
some additional information:

there is a script named "removedead.php", which is called every hour to remove unverified accounts and their email-adresses.

this script could be adapted, to remove emails-addresses with memid=0 after some time (24 hrs? 48 hrs?), too.

another solution could be to authorize critical to remove these 30 entries from the database using an sql-command (one-shot only)
(0006125)
jandd   
2022-07-07 16:20   
fix available as https://code.cacert.org/cacert/cacert-webdb/pulls/2/files


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1473 [Main CAcert Website] GPG/PGP major have not tried 2019-12-18 19:29 2022-09-22 20:07
Reporter: gleurent Platform: Default  
Assigned To: Ted OS: any  
Priority: high OS Version: any  
Status: ready to deploy Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: Ted
Test Instructions:
Summary: PGP keys are signed with SHA1
Description: You seem to be using SHA-1 to certify PGP keys of users.
I didn't try to get a signature myself, but there are many such signatures on public keyservers.
This is an important security risk because weaknesses of SHA-1 can be abused to create keys with different identities and colliding signatures.
I strongly advise that you move to a more recent hash function, such as SHA-2!
Tags: GPG
Steps To Reproduce:
Additional Information: We tried to contact you by email at support@cacert.org but got no answer.

We are two researchers working in cryptography, and we have recently
obtained important cryptanalysis results on SHA-1. We have noticed that
your CA is still signing PGP keys with SHA-1 signatures, and we believe
this an important security risk.

A few months ago we published a paper with a theoretical chosen-prefix
collision attack against SHA-1 (at Eurocrypt 2019). In the last months,
we managed to improve the attack and to run it in practice, and we have
obtained the first chosen-prefix collision against SHA-1. This work is
currently under embargo, and will be announced at the Real World Crypto
conference in early January. We are attaching the abstract of the talk
to this report.

Concretely, a chosen-prefix collision attack against SHA-1 means that we
can do the same type of attacks that have been possible against MD5
since 2009. In particular, we can abuse SHA-1 signatures and create
forgeries.

More precisely, the chosen-prefix collision that we have built is
targeted at PGP key-certification forgeries: we have created a pair of
PGP keys with different identities so that their key-certification
signatures collide with SHA-1. This means that if one of the keys is
signed with SHA-1, the signature can be transferred to the second key
(assigned CVE is CVE-2019-14855).

Apparently, CAcert is still using SHA-1 when signing user keys. For
instance the signature that you issued on key 6634000791E1DA76 on Nov 29
uses the SHA-1 hash function.

Our attack can probably not be directly applied to CAcert because we
abuse the image attribute of PGP keys, which is apparently not signed by
CAcert. However, we strongly advise you to update your system to use a
stronger hash function!
System Description Default profile.
Attached Files: SHA1_CPC.pdf (303,025 bytes) 2019-12-18 19:29
https://bugs.cacert.org/file_download.php?file_id=471&type=bug
0001-Set-GPG-digest-algorithm-to-SHA256.patch (1,364 bytes) 2020-05-16 22:19
https://bugs.cacert.org/file_download.php?file_id=475&type=bug
Notes
(0005858)
Ted   
2020-01-06 11:39   
This has to be addressed. Priority is up to discussion.
(0005875)
gleurent   
2020-04-12 14:38   
If there any news on this issue? Are you still signing PGP keys with SHA-1?
Our paper has been public for several months, so the issue doesn't need to be private anymore, but it should be fixed rapidly!
(0005884)
gleurent   
2020-05-13 13:34   
I'm sure the COVID pandemedic is making everybody's work harder, but this is an important security issue, and it have been almost six months now!
Is someone working on it?
(0005886)
jandd   
2020-05-16 22:19   
The attached patch for the release branch fixes this issue by defining the cert-digest-algo as SHA256. I tested the command line used by the patch on a very old (1.4.10) and a recent (2.2.12) gpg version in Debian Squeeze (6.0.10) and Debian Buster (10.4) Docker containers because I do not know the exact version of gpg running on the signer.
(0005887)
egal   
2020-05-17 10:21   
Patch installed on test.cacert.org (our test-server).

Please run your tests there and give us a feedback of your tests.

1st review done successfully, 2nd review needed
(0005935)
jandd   
2020-12-26 17:02   
This has been successfully tested in 0001496
(0006065)
Ted   
2021-08-07 19:33   
Created new branch bug-1473 (on github) and merged in @jandd's pull request.
(0006068)
Ted   
2021-08-07 20:04   
(Last edited: 2021-08-07 20:05)
I did a review of the code changes, and according to https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html (under "Doing things one usually doesn’t want to do") the code change should change the digest algorithm to SHA256 if the GPG version does support SHA256 at all.

Since another visit to the signer is needed for other reasons anyway, I asked @egal to check the GPG version on the server.

Assuming the GPG version does support SHA256, the review is PASSED
(0006072)
Ted   
2021-08-08 12:28   
According to @egal, the signer has GPG 1.4.9 installed, and reports SHA256 (as well as SHA512) as supported algorythm.
(0006073)
Ted   
2021-08-08 15:05   
The proposed change is now installed on <https://test.cacert.org>.

Please test it and report your results here or on <cacert-devel@lists.cacert.org>
(0006074)
Ted   
2021-08-08 15:43   
I made a test run myself:
- Create a new key with GPG, with data matching my testserver account
- Let the testserver sign the new key
- Import the signature into GPG
- Using "gpg -a --export | gpg --list-packets --verbose" to show the details of the signature.

The relevant signature packet is shown as:
:signature packet: algo 17, keyid 4BE7348177F751AC
        version 4, created 1628431932, md5len 0, sigclass 0x10
        digest algo 8, begin of digest 74 fe
        hashed subpkt 2 len 4 (sig created 2021-08-08)
        critical hashed subpkt 3 len 4 (sig expires after 1y1d0h0m)
        hashed subpkt 26 len 29 (policy: http://www.cacert.org/cps.php)
        subpkt 16 len 8 (issuer key ID 4BE7348177F751AC)
        data: 0ACD98E61F728EDC70E03D59A4401C824C8BC30C
        data: 6BB54FAA8D31E218A12A760CCBA4D42F5170237C


According to <https://datatracker.ietf.org/doc/html/rfc4880#section-9.4> "digest algo 8" stands for SHA256, which is the expected result.

Note that there are two more signature packets in the output, using SHA1 (or "digest algo 2"). IMHO these are the self signatures of the testserver's key. If anyone knows anything other please let me know!
(0006132)
alkas   
2022-09-21 12:00   
(Last edited: 2022-09-21 12:13)
The user Chris Jacobs (his Email address replaced with u@org.nl) reports: PGP certification: The cacert signature still gives an invalid digest-algorithm in Kleopatra.

> This is the info about the signatures:
>
> {quote}
>
> PS C:\Users\chris> gpg --list-sigs
> C:/Users/chris/AppData/Roaming/gnupg/pubring.kbx
> ------------------------------------------------
> pub dsa1024 2003-07-11 [SCA] [expires: 2033-07-03]
> A31D4F81EF4EBD07B456FA04D2BB0D0165D0FD58
> uid [ full ] CA Cert Signing Authority (Root CA)
> <gpg@cacert.org>
> sig 3 D2BB0D0165D0FD58 2003-07-11 CA Cert Signing Authority
> (Root CA) <gpg@cacert.org>
> sig N 0A8DCE0E49E78923 2021-09-16 Christiaan Theodoor Maria
> Jacobs <u@org.nl>
> sub elg2048 2003-07-11 [E] [expires: 2033-07-03]
> sig D2BB0D0165D0FD58 2003-07-11 CA Cert Signing Authority
> (Root CA) <gpg@cacert.org>
>
> pub rsa2048 2019-11-18 [SC]
> 77F2139E41FE00A28ABB9FF70A8DCE0E49E78923
> uid [ultimate] Christiaan Theodoor Maria Jacobs
> <u@org.nl>
> sig 3 0A8DCE0E49E78923 2021-09-02 Christiaan Theodoor Maria
> Jacobs <u@org.nl>
> sig P D2BB0D0165D0FD58 2022-09-20 CA Cert Signing Authority
> (Root CA) <gpg@cacert.org>
> sub rsa2048 2019-11-18 [E]
> sig 0A8DCE0E49E78923 2021-09-02 Christiaan Theodoor Maria
> Jacobs <u@org.nl>

> check-sigs gives better info than list-sigs:
>
> {quote}
>
> PS C:\Users\chris> gpg --check-sigs
> C:/Users/chris/AppData/Roaming/gnupg/pubring.kbx
> ------------------------------------------------
> pub dsa1024 2003-07-11 [SCA] [expires: 2033-07-03]
> A31D4F81EF4EBD07B456FA04D2BB0D0165D0FD58
> uid [ full ] CA Cert Signing Authority (Root CA)
> <gpg@cacert.org>
> sig!3 D2BB0D0165D0FD58 2003-07-11 CA Cert Signing Authority
> (Root CA) <gpg@cacert.org>
> sig! N 0A8DCE0E49E78923 2021-09-16 Christiaan Theodoor Maria
> Jacobs <u@org.nl>
> sub elg2048 2003-07-11 [E] [expires: 2033-07-03]
> sig! D2BB0D0165D0FD58 2003-07-11 CA Cert Signing Authority
> (Root CA) <gpg@cacert.org>
>
> pub rsa2048 2019-11-18 [SC]
> 77F2139E41FE00A28ABB9FF70A8DCE0E49E78923
> uid [ultimate] Christiaan Theodoor Maria Jacobs
> <u@org.nl>
> sig!3 0A8DCE0E49E78923 2021-09-02 Christiaan Theodoor Maria
> Jacobs <u@org.nl>
> gpg: Note: third-party key signatures using the SHA1 algorithm are rejected
> sig% P D2BB0D0165D0FD58 2022-09-20 [Ongeldig digest-algoritme]
> sub rsa2048 2019-11-18 [E]
> sig! 0A8DCE0E49E78923 2021-09-02 Christiaan Theodoor Maria
> Jacobs <u@org.nl>
(0006133)
Ted   
2022-09-21 19:44   
No need to keep this private since 0001496 is a duplicate (and public) case...
(0006135)
Ted   
2022-09-21 19:57   
Any other test reports?
(0006136)
Ted   
2022-09-22 20:07   
I'll take 0001496:0005934 from 0001496 as a test report, though it is not fully clear to me exactly what code change has been tested there...

Nevertheless, concerning the very minor code changes, I'll hand this over to critical for installation.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1500 [Main CAcert Website] GPG/PGP tweak always 2020-12-26 16:52 2022-09-21 19:45
Reporter: jandd Platform: Test CAcert Website  
Assigned To: OS: N/A  
Priority: normal OS Version: Test  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Issues in mail template for gpg signing response
Description: The mail that is sent out when a gpg key is signed has a few issues:

- fingerprints are hard coded but should be based on the actual key used for signing
- links are always pointing to the production system
- there are issues with quoted-printable encoding that introduce \r characters on long lines (i.e. in the gpg.php link)
Tags: GPG, mail, signer_client
Steps To Reproduce: request a GPG signature on the test system
look at the mail
Additional Information: found on the test system
System Description Test version of the CAcert website
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1496 [Main CAcert Website] GPG/PGP minor always 2020-10-31 13:48 2022-09-21 19:45
Reporter: NoSubstitute Platform: Main CAcert Website  
Assigned To: Ted OS: N/A  
Priority: normal OS Version: stable  
Status: needs review & testing Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: CAcert signed GPG key reports Invalid Digest Algorithm
Description: I'm guessing this could be why.

gpg: Note: third-party key signatures using the SHA1 algorithm are rejected
sig% P X 0xD2BB0D0165D0FD58 2019-09-22 [Invalid digest algorithm]
sig% P 0xD2BB0D0165D0FD58 2020-10-31 [Invalid digest algorithm]

>gpg --version
gpg (GnuPG) 2.2.23
libgcrypt 1.8.6
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: C:/Users/Kim/AppData/Roaming/gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
Tags:
Steps To Reproduce: Sign a gpg key with the gpg signing feature of cacert.
Import key to gpg.
Check the signatures of the key.
Additional Information: Patch created in https://bugs.cacert.org/view.php?id=1473
System Description Production version of the CAcert website
Attached Files: 2020-10-31 142414-CAcert_signed_GPG_key-Invalid_digest_algorithm.png (4,726 bytes) 2020-10-31 13:48
https://bugs.cacert.org/file_download.php?file_id=486&type=bug
2020-12-26 165239-CAcert-GPG_test-signature.png (5,896 bytes) 2020-12-26 16:00
https://bugs.cacert.org/file_download.php?file_id=490&type=bug
2020-12-26 175400-CAcert-GPG_test-signature-valid.png (9,339 bytes) 2020-12-26 16:54
https://bugs.cacert.org/file_download.php?file_id=491&type=bug
Notes
(0005924)
gleurent   
2020-12-15 13:40   
This is because SHA-1 signatures are unsafe and can be abused in practice: https://sha-mbles.github.io/
GnuPG has been rejecting them for more than one year.

I opened a bug report about one year ago (0001473) to warn CA Cert before making the attack public, but nothing has happened since and CA Cert still uses SHA-1 to certify user's PGP keys. This is really a shame.
(0005925)
L10N   
2020-12-20 09:50   
Yes, this should have been solved by now. How about you two, gleurent and NoSubstitute, take care of this case? For our volunteer software team, there would still be 1000 bugs left...
(0005926)
NoSubstitute   
2020-12-20 20:50   
I wish I had any coding skills to offer.
I can help out testing if someone else does the coding part. :-)
(0005929)
jandd   
2020-12-25 08:50   
@NoSubstitute coding is already done. It just needs to be tested. The patch has been applied on test.cacert.org since May 17th 2020.
(0005930)
NoSubstitute   
2020-12-26 14:09   
@jandd alright.

I just registered on the test system, as I didn't have an account there.
I'm not getting the email verification.
(0005931)
jandd   
2020-12-26 14:42   
@NoSubstitute thanks for volunteering for tests. The test system sends its mails to a special catchall mailbox and does not send it to the Internet. You can go to the test manager at https://test.cacert.org:14843/mail and log in with your test system credentials. This gives you access to your mails from the test system. There is a function to give you assurance points at https://test.cacert.org:14843/manage-account/admin-increase. You need 100 points to be able to use the GPG function.
(0005932)
NoSubstitute   
2020-12-26 16:00   
Thank you. That part worked great.
Managed to add points, and add secondary email, and request GPG signature.
Grabbed signature, and imported to Kleopatra, and it doesn't complain about invalid algorithm for that signature.

However, it says "no public key" (see attached image), as the test GPG key doesn't seem to be the same as the one for the PROD system, and I find no reference to where I can grab the TEST GPG key, so I can verify that the signature is fine.

Also, the email sent contains references to the PROD GPG key, as well as a download URL on the PROD system, but with one unprintable character, as seen below.

***
Hi Kim,

Your CAcert signed key for kim.nilsson@no-substitute.com is available online at:

https://www.cacert.org/gpg.php?id=3&cert054

To help improve the trust of CAcert in general, it's appreciated if you could also sign our key and upload it to a key server. Below is a copy of our primary key details:

pub 1024D/65D0FD58 2003-07-11 CA Cert Signing Authority (Root CA) <gpg@cacert.org>
Key fingerprint = A31D 4F81 EF4E BD07 B456 FA04 D2BB 0D01 65D0 FD58

Best regards
CAcert.org Support!
***
(0005933)
jandd   
2020-12-26 16:48   
@NoSubstitute thanks for testing. The test system uses a different gpg key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1

mQGiBE3TAtQRBACuFhUNT3BOIXflZx8ENFN2hf0KHDgReWMW5+hcx8M2C9mueAST
89x0QxtdWUbsrMFSr3UvDIKjoPFVzV+WT/dez5aADSrnR4OxYPfzcNIWPjm8su/9
HrH6+ivaH+iOoBOuhYrHthun+1fsqLedhTMNqb+tt6OfzqIuyFkmpm+FqwCg5ECF
s53E7j6BJuKYLeWqFDqFOH0D/1pnXyBF78YurXcwwA7eSQWoc3f1g5lwyqOWwcLv
ynI/dcPV5BosEUcqEjaNEyBR0LFRZC7tnw2VLPzr65aLA6SrFqEJ2bEdWkO9vM5g
8InhmcqTz7Yg/QGnyGT0iNBMG8zg4Ajz20Ty6GE887HMao6qpYKXSbujMRWVjVLn
VjpgA/9i1gsBjpGwr5rJ67dyDLVkJ5XMEP2ivgAhzKQ/inyLk2N3Nbm0YKWgrZRE
+pEcZVsLn2jHqd5yu1zVr3Cm44HHaB/A4ew+hRio9vbhJy7cfanfZpAL8Rg8wZbQ
t4x6zvrs0fXXNuD1BiSucOK4qGZ2vWukggmhAlHu5x5hws5qtbRLQ0FjZXJ0IFRl
c3QgU2VydmVyIFNpZ25pbmcgQXV0aG9yaXR5IChmb3IgdGVzdGluZyBvbmx5ISEh
KSA8Z3BnQGNhY2VydC5vcmc+iGYEExECACYFAk3TAtQCGwMFCSWYBgAGCwkIBwMC
BBUCCAMEFgIDAQIeAQIXgAAKCRBL5zSBd/dRrLxrAJ9kaSLRAlcy9e57yuAAxoZy
weX20ACg44B1AA26G0OePf9o3YBdUTjPsES5Ag0ETdMC1BAIAI9UEZ2NKbJfVWc+
CBb5kKhO6qazLDnRsRkMY5WE1PTBP09ieAaQ7cv424e6fKdZxSO5vUQ27tLmcQXo
ICoREsDuSyESvEPbyBOro5LIY+z52TihqEHLPUN7OxlbPLX81AIKOCgEIUtpcYoX
MiwXPVO50Swo3PCCQiOQ7ewvkd32ZbSPl50B+/59JiDsQsnx1o+Ls7WkALzQ6w7T
UxLIVYWuFd9Hg/VOXBH67e81p/O7SDy6pMkDQaA9F22rA5Vv5TBJ2BAKWYfYK47i
HxtUhw2/WBUzhcw2AGqCnCy9nrYELLAqljnlCdWLyvhuWyUAG87D/1/5qD0+9idh
jcFWH/MAAwUH/2R7AWSZzbomxTcO5Q7/WxzTDtgUEy7eRbjqFMAusiQlTYDdeHz8
PfWok6mGhUapJaGnA05hy6aYBIzl4idmQgz39xD47O0qeDWve6YwrDuLYju6JIwv
YfNiNAOjrZcRW4PCYeJfIK0WHV3+3kkneOX4Mql9QNKWs5W2LReMnHyq6POWasuf
EgDu0TfqaJTeK3IXKrEJI8G4R4xdHXmZ16Is5T49w09mvMan+TTGczzjWn0aWD3D
DOlTKK7h+82MSNCTiCi7aNoEyMTfeadSsrbqiaqtF0P/fyBDpGWFj3/A4foAcgtx
KVt0UHf1Va1g8M+czG3pCOne6dyafZGAe7qITwQYEQIADwUCTdMC1AIbDAUJJZgG
AAAKCRBL5zSBd/dRrAC5AKDdxp26zp4Km3jItBdeMD/gv8qxMgCgmmH1kizLe5Rk
yYchS2oleEWXIqM=
=9tD2
-----END PGP PUBLIC KEY BLOCK-----

The mail template is hard coded into the signer client script. The special character in the mail link may be introduced by some encoding issue. The code line in CommModule/client.pl looks sane:

$body .= "https://www.cacert.org/gpg.php?id=3&cert=$row{id}\n\n";

but maybe the Content-Transfer-Encoding: quoted-printable in the sendmail function in the same script breaks the content. I will file a separate bug for the mail template issues.
(0005934)
NoSubstitute   
2020-12-26 16:54   
With the test key imported the signature looks great.
(0005943)
jandd   
2021-01-31 11:17   
@Ted seems like the patch has been tested successfully. What are the next steps to get it in the production system (I know a site visit because it is code on the signer). Someone needs to merge the code into the proper branch and make a formal delivery to the critical team? Do we have a documentation of how this should be done? Can we add such a documentation to codedocs?
(0005952)
Ted   
2021-02-01 21:29   
@jandd, those were exactly the questions which discouraged me to continue work on this bug... The signer machine is something like a big black box to me. :-\

First of all the changes have to be reviewed by a Software Assessor, probably me. Where are these changes archived? I did not find a branch-1496 in the cacert-devel repository on github or git.cacert.org (is the signer sofware part of this repository at all? Only CommModule/server.pl?), is it somewhere in the svn repository? Or where else can I have a look at what was changed?

The next question is whether the installation on the testserver is sufficiently simmilar to the signer installation. I did not find the signer machine on infradocs, am I looking at the wrong places? Maybe @egal can give some info here? Or to we have to ask Wytze? Without knowing the file layout on the signer it's quite hard to create some auditable install package.
(0006039)
NoSubstitute   
2021-07-28 09:54   
Awww, what a shame no progress was made on this now that there was a forced trip to the server.
Created a new signature for my GPG key today, and it's also invalid; just like it has been since 2019.
(0006134)
Ted   
2022-09-21 19:45   
IMHO this is a duplicate of 0001473, we should continue work there.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1537 [Community.cacert.org] misc minor N/A 2022-01-07 00:15 2022-07-10 13:06
Reporter: L10N Platform: Main CAcert Website  
Assigned To: OS: N/A  
Priority: normal OS Version: stable  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Update policies after vote at Policy Group in September 2020
Description: In September 2020, Policy Group voted some minor changes in two policies and the CCA in view of the move to Europe.
These changes must be updated in the original.
Tags:
Steps To Reproduce:
Additional Information: p20200923 Minor changes at Privacy Policy and the Root Distribution License

Resolved, that the geographical references of CAcert Inc. which are not mandatory in terms of content are removed from the Privacy Policy and the RDL:

=====================================
RDL COD14 Root Distribution License
_/ from existing p20140731 _/
RDL 1 Terms:
'"CAcert Inc" means CAcert Incorporated, a non-profit association incorporated in New South Wales, Australia.'

_/ change to proposed _/
RDL 1 Terms:
'"CAcert Inc" means CAcert Incorporated, a non-profit association.'
=====================================

=====================================
PP COD05 Privacy Policy
_/ from obsolete m20060629 _/
PP 10 Legal mandates:
'If you need to contact us in writing, address your mail to:
CAcert Inc.
PO Box 66
Oatley NSW 2223
Australia'

_/ change to proposed _/
PP 10 Legal mandates:
'If you need to contact us in writing, address your mail to the postal address of CAcert Inc. The current postal address of Cacert Inc. can be found on CAcert's web site.'
=====================================

************************************************

p20200930 Minor changes at the CAcert Community Agreement

Resolved, that the geographical references of CAcert Inc. which are not mandatory in terms of content are removed from the CAcert Community Agreement (while retaining all references to common law concerning the Community):

=====================================
CCA COD09 CAcert Community Agreement
_/ from existing p20141008 _/
CCA 0.1 Terms:
'"CAcert" means CAcert Inc., a non-profit Association of Members incorporated in New South Wales, Australia.'

_/ change to proposed _/
CCA 0.1 Terms:
'"CAcert" means CAcert Inc., a non-profit Association of Members.'
=====================================

=====================================
CCA COD09 CAcert Community Agreement
_/ from existing p20141008 _/
CCA 3.1 Governing Law
'This agreement is governed under the law of New South Wales, Australia, being the home of the CAcert Inc. Association.'

_/ change to proposed _/
CCA 3.1 Governing Law
'This agreement is governed under the law of New South Wales, Australia.'
=====================================
System Description Production version of the CAcert website
Attached Files:
Notes
(0006094)
L10N   
2022-01-07 00:18   
I updated RDL COD14 Root Distribution License, PP COD05 Privacy Policy and CCA following the voting text at github and sent a pull request. If there is a review needed, please review it (twice?) and if it is OK, publish it, please.
(0006095)
SaT   
2022-01-07 16:55   
I started a review in GitHub as second reviewer to mcr.
(0006096)
mcr314   
2022-01-07 16:56   
I don't understand why the governing law would still be New South Wales.
What is our new postal address in CH?
(0006100)
L10N   
2022-01-09 20:34   
There are significant differences between common law and Napoleonic law. Since all our internal policies were based on common law, we kept it that way. Anything else would be opening Pandora's box. What has changed with the relocation of the seat: Swiss law instead of NSW law now applies to the association's relationship with the country of location.
(0006129)
jandd   
2022-07-10 12:35   
@SaT @L10N @mcr314 could one of you please link to relevant GitHub repository and commits or pull requests? Links are always better that ambiguous textual descriptions.
(0006130)
L10N   
2022-07-10 13:06   
This are 0000034 and 0000035 at https://github.com/CAcertOrg/cacert-devel/pulls


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1540 [Main CAcert Website] certificate issuing major always 2022-05-31 19:30 2022-07-10 12:02
Reporter: alkas Platform: Default  
Assigned To: OS: any  
Priority: high OS Version: any  
Status: needs review & testing Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions: Perform a dump of the Class 3 Root certificate
Summary: Class 3 Root doesn't contain attributes X509v3 Subject Key Identifier & X509v3 Authority Key Identifier & X509v3 Key Usage
Description: Intermediate certificate:
Key usage required, but our class 3 cert seems to not have the key usage extension ("X509v3 Key Usage"). End-user certs do have it.
The wrong Issuer URL leads to failing checks of the trust chain.

See the attached picture comparing the new (SN=14E288, left side) and the old (SN=0A418A, right side) Class 3 Roots.
You can see that both the attributes mentioned are missing.
Tags: certificates, Class 3, Class 3 Root, class3
Steps To Reproduce:
Additional Information:
System Description Default profile.
Attached Files: Class_3_compare.gif (42,257 bytes) 2022-05-31 19:30
https://bugs.cacert.org/file_download.php?file_id=517&type=bug
Class_3_compare_0Ex14E228.gif (63,293 bytes) 2022-05-31 20:54
https://bugs.cacert.org/file_download.php?file_id=518&type=bug
class3_demo.crt.txt (7,810 bytes) 2022-07-10 12:01
https://bugs.cacert.org/file_download.php?file_id=520&type=bug
Notes
(0006113)
alkas   
2022-05-31 20:54   
The difference between Class 3 Root SN=00000E and Class 3 Root SN=14E228. See the picture. Another diffs = dates only.
(0006114)
alkas   
2022-06-01 07:33   
Google Workspace, Hosted S/MIME service.
There are two instructions how to make a certificate chain.

https://support.google.com/a/answer/7300887?hl=en
https://support.google.com/a/answer/6374496#zippy=%2Cconstruct-the-certificate-file-for-upload
(0006115)
alkas   
2022-06-02 14:21   
A problem with the X509v3 Authority Key Identifier creating a new CA certificate, please see:
https://v13.gr/2013/04/11/x509v3-authority-key-identifier-authoritykeyidentifier/
(0006128)
jandd   
2022-07-10 12:01   
I wrote documentation and an openssl configuration file for re-signing the class3 CA certificate. We will not be able to fullfil all of Google's requirements with our current CA hierarchy.

The re-signing documentation and configuration file is available at https://code.cacert.org/cacert/signing-documentation. A demo class3 CA certificate signed by a local Test VM produces the text representation attached here.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
813 [Infrastructure] General feature sometimes 2010-03-26 16:00 2022-07-07 17:32
Reporter: jomat Platform:  
Assigned To: egal OS:  
Priority: normal OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: rDNS of IPv6 for mailserver
Description: Hi!

I can't receive emails of your server. This is the log:

Mar 26 16:41:24 myserver postfix/smtpd[32234]: warning: 2001:7b8:3:9c::245: address not listed for hostname www.cacert.org
Mar 26 16:41:24 myserver postfix/smtpd[32234]: connect from unknown[2001:7b8:3:9c::245]
Mar 26 16:41:24 myserver postfix/smtpd[32234]: NOQUEUE: reject: RCPT from unknown[2001:7b8:3:9c::245]: 450 4.7.1 Client host rejected: cannot find your hostname, [2001:7b8:3:9c::245]; from=<returns@cacert.org> to=<webmaster@mydomain.com> proto=SMTP helo=<hlin.cacert.org>
Mar 26 16:41:24 myserver postfix/smtpd[32234]: disconnect from unknown[2001:7b8:3:9c::245]

Johannes
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006127)
jandd   
2022-07-07 17:32   
we should create proper PTR records for ping.cacert.org now that 0001541 has been deployed


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1542 [Main CAcert Website] translations minor always 2022-07-06 20:31 2022-07-07 17:03
Reporter: egal Platform: Main CAcert Website  
Assigned To: egal OS: N/A  
Priority: normal OS Version: stable  
Status: solved? Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: egal
Test Instructions: not possible to test on current testserver-environment as debian on these machines is too old
Summary: translation not working
Description: After the update to Debian 11 translation using gettext-functionality is not working anymore, so Main Website is on english only no matter of the language selection.

Reason is a variable change on the way from Debian 8 to Debian 11 from LANG to LANGUAGE for the gettext-module.

This has to be reflected in /www/includes/lib/l10n.php
Tags:
Steps To Reproduce: open www.cacert.org, select other language than english, web-site will stay on english
using testserver, you will see the web-site in selected language
Additional Information:
System Description Production version of the CAcert website
Attached Files:
Notes
(0006123)
jandd   
2022-07-07 15:58   
A fix is available as https://code.cacert.org/cacert/cacert-webdb/pulls/1/files
(0006124)
egal   
2022-07-07 16:09   
review is passed ...

additionally: ran a test in my own environment, works successfully
as the only change is the name of the environment-variable, a second review is not necessary in this case

the change could be deployed on productive server to file /www/includes/lib/l10n.php
(0006126)
jandd   
2022-07-07 17:03   
patch has been applied on webdb, language selection works

PR has been merged in https://code.cacert.org/cacert/cacert-webdb/commit/2884caf1a519a43fa4fa36a0afa06c5935884914


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1541 [Main CAcert Website] my account minor always 2022-07-04 15:56 2022-07-07 15:09
Reporter: egal Platform: Default  
Assigned To: egal OS: any  
Priority: normal OS Version: any  
Status: solved? Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: egal, Ted
Test Instructions:
Summary: ping-testmails are rejected due to wrong IP-adress
Description: previously www.cacert.org was running on sun2 with a direct internet-connection ...

... during the transition to sun1 is behind the firewall and the direct connection was removed.

when trying to deliver the ping-mail, www.cacert.org send in SMTP-commands:

EHLO www.cacert.org

as this does not match the IPv4 or IPv6-address of www.cacert.org, the mailserver on remote site rejects the mail:

postfix/smtpd[897930]: NOQUEUE: reject: RCPT from unknown[2001:7b8:616:*:*::11]: 450 4.7.25 Client host rejected: cannot find your hostname, [2001:7b8:616:*:*::11]; from=<returns@cacert.org> to=<*@*.me> proto=ESMTP helo=<www.cacert.org>

possible solutions:

(1) change hostname in general.php to "something else", so the name/ip-adress-pair could be added to nameservers
(2) deliver ping-emails via postfix/emailout, but in this case the user will not get a direct feedback, if the ping-mail could not be sent

Tags: mail, webdb
Steps To Reproduce: try to add new email-adress to existing account when the target mailserver is verifiying hostnames/...
Additional Information:
System Description Default profile.
Attached Files: ping-test-mail.patch (718 bytes) 2022-07-04 17:08
https://bugs.cacert.org/file_download.php?file_id=519&type=bug
Notes
(0006116)
jandd   
2022-07-04 17:08   
The attached patch changes the EHLO name from www.cacert.org to ping.cacert.org
(0006117)
egal   
2022-07-04 17:23   
(Last edited: 2022-07-04 17:28)
hostname of server in EHLO-command was changed, no other change was done
a test on test.cacert.org is not possible in this case due to other hostname (and behaviour for testing) on this server
ready for deployment on webdb/sun1-server

(as this a minor text-change and no change in coding, no second review is needed)
(0006118)
egal   
2022-07-04 17:24   
please deploy on productive server
(0006119)
jandd   
2022-07-04 18:30   
the patch has been deployed on webdb1
(0006120)
Ted   
2022-07-05 18:00   
Just in case anybody cares, I can also give a passed review to this change.
(0006122)
jandd   
2022-07-07 15:09   
committed as https://code.cacert.org/cacert/cacert-webdb/commit/9140217aa70f42b55a105c90641ace5d04dd6ff6


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1539 [Main CAcert Website] certificate issuing major N/A 2022-03-25 21:15 2022-03-27 20:15
Reporter: Ted Platform:  
Assigned To: Ted OS:  
Priority: high OS Version:  
Status: needs testing Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: Ted
Test Instructions:
Summary: Implement an emergency workaround for 0000769
Description: I'm splitting this off from 0000769 so we can do the usual change documentation for the emergency workaround, since 0000769 will probably need several additional code changes...

Note that in the git repositories bug-769 is used for changes concerning this bug. At least until we find a reason to create a specific branch for this. ;-)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: alkas@volny.cz_J5BC7.crt (1,992 bytes) 2022-03-26 22:54
https://bugs.cacert.org/file_download.php?file_id=515&type=bug
lech@convey.de.crt (2,004 bytes) 2022-03-27 12:04
https://bugs.cacert.org/file_download.php?file_id=516&type=bug
Notes
(0006105)
Ted   
2022-03-25 22:29   
The changes from the pull request should now be active on the testserver https://test.cacert.org

@alkas can you try to request a certificate with non ISO-8859-1 characters and tell us what happens?
(0006106)
alkas   
2022-03-26 22:54   
The certificate was issued, no problems encountered. The cert "Ale? Kastner" ("?"="ě") can login to the testserver. See the cert attached. Possibly Wacław Schiller should perform the test with his original name. (? - can stop the signer)
(0006107)
Ted   
2022-03-27 12:00   
(Last edited: 2022-03-27 12:04)
Thank you Aleš, but it looks like I'm wrong in assuming that your name has also provoked the error, maybe because your first name is stored "directly" in the database table (no HTML encoding)?

I now tried the more difficult name "Lech Wałęsa", which uses two of the more "notorious" polish characters. This one got stored in the database HTML encoded as "Wałęsa". When I requested a certificate containing that name I got a result containing

Subject: CN = "Lech Wałęsa", emailAddress = lech@convey.de

(openssl x509 -text shows it in HTML encoding, looks like Mantis does not quote them...)
Though this may not conform ASN specification, this is what I'd expect from the current setup, where the name is stored HTML encoded.
In comparison my certificate includes

Subject: CN = Bernhard Fr\C3\B6hlich, emailAddress = ted@convey.de, emailAddress = froehlich@convey.de

which is (correct?) UTF-8, while your certificate has

Subject: CN = Ale\C2\9A Kastner, emailAddress = alkas@volny.cz

which is probably not correct UTF-8 (š would be \C5\A1, wheres ě should be \C4\9B...).
I'll now rollback the change and try if I can provoke the signer "crash" then.
(0006108)
Ted   
2022-03-27 12:04   
(0006109)
alkas   
2022-03-27 17:14   
The same both in Windows and Linux Ubuntu: displaying in account is OK, displaying of an issued cert - white space or a square.
\C2\9A is 2-byte 9A code taken from Wndows ANSI CP-1250, no conversion to Unicode.
(0006110)
Ted   
2022-03-27 19:56   
In a session with Jan and Dirk I now find out what this workaround should do:

It checks the subject and SAN of the internally created CSR (which is not the same as the uploaded CSR) for "evil characters".
If the server.pl receives any of these "evil characters" it will terminate, but the client.pl is not notified, so it will continue to send the CSR (and therefor teminating the server.pl), which effectively blocks all certificate issuing.

Some "evil characters" have already been handled before, this workaround additionaly checks for the hash "#", which is also considered "evil" by server.pl

So, with this workaround, CSR for names containing hash characters, which most prominently includes all HTML encoded characters (most characters outside ISO-8859-1), are not sent to the signing server.
(0006111)
Ted   
2022-03-27 20:03   
Also in the session with Jan and Dirk we found a bug in the pull request and fixed it.

Now, if I request a certificate for "Lech Wałęsa" the certificate remains in the list of client certificates with status "Pending", but I still can issue certificates for my name. This is by far not the ideal solution, but it is not worse than before and saves us support work.

The code review which went with the tests, is a PASS
(0006112)
Ted   
2022-03-27 20:14   
(Last edited: 2022-03-27 20:15)
I would appreceate an additional test reports from someone else.

Please create a new account for a name containing some greek, kyrillic, japanese character(s), or somply add a hash character to the name. Certificate issuing should not be work for these names.

Then create an account wit a name from ISO-8859-1 characters (or use an existing one), certificate issuing should work for them.

@alkas: The š character is some special case. It is stored without HTML encoding, though it is not part of ISO-8859-1. I indeed do not understand completely what is happening there, but it should not count as "evil character", so you probably can issue certificates on the testserver as before.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
769 [Main CAcert Website] certificate issuing crash have not tried 2009-08-15 13:18 2022-03-25 21:18
Reporter: nijel Platform:  
Assigned To: Ted OS:  
Priority: urgent OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Client certificate broken with unicode
Description: While generating client certificate, I got certificate with name "Michal &". I guess something went wrong when processing unicode name "Michal ?iha?".
[The surname could be for example "Čihař".]
Tags: CATS, certificates, charset, diacritic, iso-8559-1, latin1, names, unicode, utf-8
Steps To Reproduce: Tried generate a client cert on the testsys. My name contains "š" (s-caron). It is taken from my account, where I suppose is OK (displayed OK in my account). However, it is CP-1250 one-byte coded in the client cert created. As client cert is probably UTF-8 (two-bytes for diacritic) coded, this CP-1250 coding is wrong.
Additional Information: Such error occurs in Win/IE, Win/Chrome, and also Linux Ubuntu/Mozilla Firefox, Linux OpenSuSE/Mozilla Firefox.
This error can be also seen at the beginning of e-mail notices about end of cert's validity. E.G.: Hi Ale�, (etc.) usually I can only read "Hi Ale,". The last char of my name depends on the mail client. Here the hex representation was FDFF meaning the information was lost. Another clients show 9A00 (CP-1250), or C2006101. The correct Unicode representation is 6101 only. The correct UTF-8 representation is C5A1. The representation in the cert is 9A (CP-1250). It would be correct, if this text in the cert was preceded by a coding type and codepage number (I do not know if it is).
Attached Files:
Notes
(0005460)
alkas   
2015-08-29 20:51   
This error is very unpleasant, as it concerns the basic info - user's name.
As of certs with names I am not Aleš anymore, but Ale (beer) only.
(0006055)
alkas   
2021-08-06 16:28   
The certificate interpreter suppose the CN name is coded as UTF-8. In fact, the name is coded CP-1250 (Latin2). From where does it come? If you make a CSR with CN=name, then the name is properly coded in UTF-8. So there are following 2 possibilities:
1. The name is taken from the user's account and possibly converted into CP-1250 representation. But the document CPS (COD6) in 3.1.1 says that the CN (and OU) are NOT coming from the member's account!
2. The name is taken from CSR and then converted into member's national CP. This behaviour possibly remains from days before UTF-8 arised.
Conclusion: Probably an unnecessary conversion is performed.
(0006061)
jandd   
2021-08-07 10:54   
(Last edited: 2021-08-07 10:55)
The web site software has a lot of hardcoded latin1 assumptions, even the database is encoded in latin1/iso-8859-1. Database migrations and a full retest of registration, assurance and certificate issuing is required to fix this. I need to check whether the signer also has assumptions about the charset. I agree that this is unacceptable in 2021 and that the whole site and software should use UTF-8/Unicode.

At least CATS is affected by this too and uses Latin1 instead of UTF-8.
(0006075)
Golffies   
2021-08-25 13:28   
On the 2nd of August, a certificate requested by Wacław triggered the bug. It requiered from Dirk and Michaela to go to Ede, and reset the signer script manually.
(0006076)
alkas   
2021-08-25 16:17   
A little research has discovered a severe bug.
1. Encoding/decoding names and other texts containing characters outside ASCII table, e.g. ANSI/ISO CPs are not encoded/decoded entering/leaving accounts. BUT, the standard representation (at least in Windows) changed during all the CAcert years - since founded. THIS MEANS that the representation of names considered as very important by CAcert - also changed. In my case, when I created my account in 2014, my Windows sent my name in ANSI/ISO. Now it is UTF-8. When creating a certificate, CAcert's software does no conversion. Certificates are supposed to have text fields in UTF-8. So, old accounts could have ANOTHER representation of names then new ones! (Provided that accounts were/are created from Windows.)
2. The CAcert sotware has/had no tools to discover the code and convert it to UTF-8.
3. Even after repairing the signer software, these names/dates/other texts (security questions) will suffer. In fact, there are users complaining that they are unable to answer security questions.
(0006077)
jandd   
2021-08-25 16:48   
some data points from our research:

- Web application only support ISO-8859-1, everything else is encoded as HTML entity and written to the database in the encoded representation and enforces ISO-8859-1 on incoming requests
- the database stores data with latin1_ci_swedish, the ancient MySQL default collation
- the client.pl that sends data to the signer takes the HTML encoded form of SubjectDN and SubjectAlternativeName fields literaly and sends it to the signer
- server.pl on the signer has a error condition that fails on &#<number>; encoded entities in SubjectDN, this crashes server.pl, so no response is sent to the signer client and client.pl runs into a timeout. The request with the broken SubjectDN is sent to the signer and crashes server.pl until manual intervention
- the openssl configuration on the signer (ancient Debian 5 openssl) takes the ISO-8859-1 data literally but marks them as ASN.1 T61String which is wrong. No reencoding is done and therefore ISO-8859-1 characters above the ASCII character set like 'â' are not encoded correctly and can not be displayed by conforming X.509/ASN.1 implementations

So we have an encoding problem on all these levels. A proper solution would be to reimplement everything to use UTF-8 and implement data migration procedures at least for all the values in the subject column(s) of the relevant database table(s).

To protect the signer's server.pl from future crashes we need to perform the same checks of the subject string in client.pl and do not send requests to the signer that will crash server.pl. This means:
- that we can not issue certificates for anybody who has a character that is not in ISO-8859-1 in his name (that will be encoded as numbered HTML entity by the web application)
- that certificates that contain a subject DN that is valid in ISO-8859-1, but contains characters that have a different meaning in ASN.1 T61String will still be issued but will have a wrong encoding for the CN part of the Subject DN

An UTF-8 implementation should be done in several - individually testable - steps:

1.) reimplement the signer software (currently server.pl) in a language that supports Unicode properly, still speak the old protocol but convert incoming Subject DN information to UTF-8 and create certificates with ASN.1 UTFString encoding for the Subject DN fileds
2.) reimplement the signer client (currently client.pl) to do the conversion, implement a proper protocol between signer client and server that can properly contain UTF-8 characters, has proper framing, error signaling and so on. I have ideas how to do this but still need to write the specification.
3.) implement a set of automated tests with representative data especially for non western-european / english contries (everything not covered by 7bit ASCII) to have a set of regression tests for step 4
4.) reimplement the Web application and implement data migration code to transform the database to UTF-8/Unicode (MySQL uses a 4 Byte Unicode representation utf8mb4 internally). This does only make sense with a proper set of tests from 3)

I know this is a huge undertaking but from my point of view this is necessary if we want to stay relevant, gain new community members or implement any new use cases based on our certificates (i.e. OAuth2/OpenID connect federated login, or any other new standard that is using Unicode/UTF-8).
(0006078)
egal   
2021-08-25 20:23   
Following: https://bugs.cacert.org/view.php?id=769#c6075 by Golffies

This issue triggered a visit at the Signer for me and Michaela, but (after investigation) it has been solved remotely on webdb-server.

Means: Whenever it happens again, a visit at the datacenter is not necessary, but manual remote interaction by critical team is necessary on webdb.
(0006083)
jandd   
2021-08-26 15:29   
I implemented a mitigation for the server.pl crash in https://github.com/CAcertOrg/cacert-devel/pull/31
(0006103)
Ted   
2022-03-25 20:37   
I now created a new pull request https://github.com/CAcertOrg/cacert-devel/pull/36 (should have the same content) against the more convenient branch bug-769. This fits better to our dev process...
(0006104)
Ted   
2022-03-25 21:18   
I split off this emergency workaround into 0001539, to get more consistent documentation.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1498 [Main CAcert Website] certificate issuing major always 2020-11-18 18:34 2022-03-18 16:57
Reporter: alkas Platform: Default  
Assigned To: OS: any  
Priority: high OS Version: any  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Mail notices about downloading issued certs contains old roots' fingerprints
Description: Here is an example:
---
Hi Support,

You can collect your certificate for kristen.lss.ie by going to the following location:

https://www.cacert.org/account.php?id=15&cert=814814

If you have not imported CAcert's root certificate, please go to:
https://www.cacert.org/index.php?id=3
Root cert fingerprint = A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B
Root cert fingerprint = 135C EC36 F49C B8E9 3B1A B270 CD80 8846 76CE 8F33

Best regards
CAcert.org Support!
---
The "root cert fingerprints" do not agree with those published on the CAcert web (roots page), they are probably old ones.
Tags: certificates
Steps To Reproduce: See the example. It was captured today, 20201118, still 20210501
Additional Information:
System Description Default profile.
Attached Files: usbclient.pl (25,314 bytes) 2021-07-16 13:22
https://bugs.cacert.org/file_download.php?file_id=508&type=bug
client.pl (29,547 bytes) 2021-07-16 13:22
https://bugs.cacert.org/file_download.php?file_id=509&type=bug
Notes
(0006036)
alkas   
2021-07-16 13:22   
The following modules client.pl and usbclient.pl should replace the modules of the same names in ...cacert\CommModule\
(0006102)
alkas   
2022-03-18 16:57   
20220319 - still not corrected in mails reporting a new cert


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
973 [CATS.cacert.org] Translation: Content minor N/A 2011-08-22 21:19 2022-01-10 14:12
Reporter: Ted Platform:  
Assigned To: Ted OS:  
Priority: normal OS Version:  
Status: needs review & testing Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Translation of Assurer Challenge to French
Description: This is to keep track of the current status of the translation.
Tags: CATS, Translation
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002319)
Ted   
2011-08-22 22:11   
Current status:

About 20% completed
(0003259)
Lordguy   
2012-10-17 20:54   
(Last edited: 2012-10-17 21:53)
traduction à 100% du test Org assurer

(0004450)
L10N   
2013-11-09 23:25   
Qu'est-ce qui manque encore pour terminer?
Was fehlt noch, bis es fertig ist?
What is still missing to finish?
(0005193)
L10N   
2014-12-18 21:36   
Qu'est-ce qui manque encore pour terminer?
Was fehlt noch, bis es fertig ist?
What is still missing to finish?
(0005551)
L10N   
2017-06-30 20:25   
Qu'est-ce qui manque encore pour terminer?
Was fehlt noch, bis es fertig ist?
What is still missing to finish?
(0005578)
bergerc   
2018-03-18 21:49   
I modified some translations (french). What are the next tasks ?
(0005582)
jandd   
2018-04-06 09:26   
https://translations.cacert.org/fr/cats/ seems to be complete now
(0005610)
Ted   
2018-09-04 07:36   
I don't know if we are talking about the same thing here.

This is the case to translate the test questions, not the user interface. The test questions are not (and will probably never be) on https://translations.cacert.org!

At the moment translating and reviewing the test questions is a bit complicated, see https://wiki.cacert.org/Brain/Study/EducationTraining/CATSTranslation...

I'll try to create HTML files for a review of the french test questions in the next few days and publish a link here.
(0005613)
Ted   
2018-10-21 18:50   
The current state of the french translation of the Assurer Challenge can now be found at https://cats.test.cacert.org:14843/fr.html

This is the CATS test system, be prepared that your browser will probably complain about an invalid certificate.
(0005724)
L10N   
2019-01-02 20:24   
Hi Ted,
all 96 questions/answers are now translated, that means 100% of the Assurer Challenge.
Review is needed.
(0005725)
L10N   
2019-01-02 20:27   
In 2012, Lordguy wrote (https://bugs.cacert.org/view.php?id=973#c3259), that the OrgA Test is 100% translated. Is OrgA Test in production or is a review needed?
(0005730)
Ted   
2019-01-03 21:20   
An updated version of the french review sheet is available at https://cats.test.cacert.org:14843/fr.html (for the time of the review). The first thing i noticed was that question [3] and the answers to [4] are still english? >:-)

OrgA Test is not installed on the production CATS, so I'd take this as a hint that it is currently not in use.
(0005922)
L10N   
2020-12-03 22:28   
Ted, would you mind to update https://cats.test.cacert.org:14843/fr.html please?

I went trough the document and looked out for all English remainings (just "true" and "false" remains). As we have three French speaking people in the board, I have some hope, the review will be done soon after.
(0006088)
L10N   
2021-12-29 21:00   
Ted, would you mind to update https://cats.test.cacert.org:14843/fr.html please?

I went trough the document and looked out for all English remainings (just "true" and "false" remains). As we have three French speaking people in the board, I have some hope, the review will be done soon after.
(0006093)
Ted   
2022-01-06 18:12   
Sorry, I overlooked this... https://cats.test.cacert.org:14843/fr.html should now be up to date.
(0006099)
L10N   
2022-01-09 20:26   
Thank you Ted! I do not remember, where the translation were done, maybe dans cats.cacert.org, but as my browser has a new certificate, it taktes me as a new user?!

Two answers (23 and 26) are in English. I translate them as follows. To go forward, I put the translations here, so the reviewers can start and review this two answers here and we can put them to the right place after the review, can we?

=== Answer 23 ===
"Un document périmé n'est plus valable. S'il a expiré récemment (<1 an), vous pouvez l'accepter à vos risques et périls, mais n'oubliez pas que vous devrez peut-être l'expliquer à l'avenir!"

=== Answer 26 ===
"Si la carte d'identité est périmée, elle n'est pas acceptable, mais si elle est juste vieille..."
(0006101)
Ted   
2022-01-10 14:12   
See https://wiki.cacert.org/Brain/Study/EducationTraining/CATSTranslation "Test Translation".
You'll have to log in with your current certificate and tell me the serial number, then I'll make you test admin.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1533 [Main CAcert Website] website content major always 2021-07-14 14:13 2022-01-09 19:33
Reporter: alkas Platform: Main CAcert Website  
Assigned To: Ted OS: N/A  
Priority: normal OS Version: stable  
Status: needs review & testing Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: CAP forms should contain the sha1 & sha256 of the new Class 3 Root
Description: The CAP pattern still contains Fingerprints of the old Class 3 Root.
Tags: CAP, class3, fingerprints
Steps To Reproduce: Download CAPs and inspect them.
Additional Information:
System Description Production version of the CAcert website
Attached Files: coapnew.php (77,467 bytes) 2021-07-16 13:31
https://bugs.cacert.org/file_download.php?file_id=510&type=bug
cap.php (13,885 bytes) 2021-07-16 13:31
https://bugs.cacert.org/file_download.php?file_id=511&type=bug
capnew.php (77,644 bytes) 2021-07-16 13:31
https://bugs.cacert.org/file_download.php?file_id=512&type=bug
ttp.php (10,565 bytes) 2021-07-16 13:31
https://bugs.cacert.org/file_download.php?file_id=513&type=bug
3.php (3,910 bytes) 2021-07-16 13:53
https://bugs.cacert.org/file_download.php?file_id=514&type=bug
Notes
(0006037)
alkas   
2021-07-16 13:31   
replace named PHP'S in ...cacert\www\ with the following PHP's:
(0006038)
alkas   
2021-07-16 13:53   
also cacert\pages\index\ replace 3.php with the following:
(0006040)
L10N   
2021-08-03 21:59   
see here https://wiki.cacert.org/Roots/Class3ResignProcedure/FingerprintSources
(0006041)
L10N   
2021-08-03 22:20   
this seems to be outdated. It's here:
/www/cap.html.php
/www/capnew.php
/www/coap.html.php
/www/coapnew.php
at github
if someone tells me the new fingerprints, I can do it.
(0006042)
alkas   
2021-08-05 09:43   
From the main web:
Class 1 Root, serial # 00000F
    SHA256 fingerprint: 07ED BD82 4A49 88CF EF42 15DA 20D4 8C2B 41D7 1529 D7C9 00F5 7092 6F27 7CC2 30C5
    SHA1 fingerprint: DDFC DA54 1E75 77AD DCA8 7E88 27A9 8A50 6032 52A5
Class 3 Root, serial # 14E228
    SHA256 fingerprint: 1BC5 A61A 2C0C 0132 C52B 284F 3DA0 D8DA CF71 7A0F 6C1D DF81 D80B 36EE E444 2869
    SHA1 fingerprint: D8A8 3A64 117F FD21 94FE E198 3DD2 5C7B 32A8 FFC8

Please verify also the mail address, if
CAcert Inc. - Hangar 10 Airfield Avenue - Murwillumbah NSW 2484 - Australia
or (in the future ?)
   CAcert Inc.
   Etienne Ruedin, Secretary
   Clos-Belmont 2
   CH-1208 Geneva
   Suisse - Switzerland

Thanks, Aleš (alkas)
(0006047)
L10N   
2021-08-05 19:58   
I did the changes at github. see pull request 0000024 "new fingerprints & new postal adress (both 2021)"
(0006057)
Ted   
2021-08-06 22:34   
(Last edited: 2021-08-06 22:34)
Created a new branch bug-1533 and merged the pull request into the new branch.

Merged bug-1533 into test-1442 and installed it on <https://test.cacert.org/>. The change can now be tested on the testserver.
(0006087)
L10N   
2021-12-29 20:55   
I connected to the testserver and opened a WoT-Form https://test.cacert.org/cap.php?name=Hans+Dampf+&dob=2014-01-01&email=hans%40dampf.org
issues:
- old adress
- class 3 not as mentionned above
+ root as mentionned above


CAcert Inc. - Hangar 10 Airfield Avenue - Murwillumbah NSW 2484 - Australia - http://www.CAcert.org
Empreinte du certificat racine de CAcert (since 2019)
SHA1: root: DDFC DA54 1E75 77AD DCA8 7E88 27A9 8A50 6032 52A5 et class3: A7C4 8FBE 6B02 6DBD 0EC1 B465 B88D D813 EE1D EFA0
SHA256: root: 07ED BD82 4A49 88CF EF42 15DA 20D4 8C2B 41D7 1529 D7C9 00F5 7092 6F27 7CC2 30C5 et class3: F687 3D70 D675 96C2 ACBA 3440 1E69 738B 5270 1DD6 AB06 B497 49BC 5515 0936 D544
(0006092)
Ted   
2022-01-06 17:55   
Merged in pull request 30 from @alkas, which seems to address this topics.

Note that the PDF creation library does not seem to handle UTF-8, so I recoded the è from Genève to CP-1252.
(0006098)
L10N   
2022-01-09 19:33   
I connected to the testserver and opened a WoT-Form in French DIN A4:
CAcert Inc., Clos Belmont 2, 1208 Genève, Suisse - http://www.CAcert.org
Empreinte du certificat racine de CAcert (since 2021)
SHA1: root: DDFC DA54 1E75 77AD DCA8 7E88 27A9 8A50 6032 52A5 et class3: D8A8 3A64 117F FD21 94FE E198 3DD2 5C7B 32A8 FFC8
SHA256: root: 07ED BD82 4A49 88CF EF42 15DA 20D4 8C2B 41D7 1529 D7C9 00F5 7092 6F27 7CC2 30C5 et class3: 1BC5 A61A 2C0C 0132 C52B 284F 3DA0 D8DA CF71 7A0F 6C1D DF81 D80B 36EE E444 2869

as well as in German DIN A4:
CAcert Inc., Clos Belmont 2, 1208 Genève, Suisse - http://www.CAcert.org
Fingerabdrücke der CAcert-Stammzertifikate (since 2021)
SHA1: root: DDFC DA54 1E75 77AD DCA8 7E88 27A9 8A50 6032 52A5 und class3: D8A8 3A64 117F FD21 94FE E198 3DD2 5C7B 32A8 FFC8
SHA256: root: 07ED BD82 4A49 88CF EF42 15DA 20D4 8C2B 41D7 1529 D7C9 00F5 7092 6F27 7CC2 30C5 und class3: 1BC5 A61A 2C0C 0132 C52B 284F 3DA0 D8DA CF71 7A0F 6C1D DF81 D80B 36EE E444 2869

and in English US size:
CAcert Inc., Clos Belmont 2, 1208 Genève, Suisse - http://www.CAcert.org
CAcert's Root Certificate fingerprints (since 2021)
SHA1: root: DDFC DA54 1E75 77AD DCA8 7E88 27A9 8A50 6032 52A5 and class3: D8A8 3A64 117F FD21 94FE E198 3DD2 5C7B 32A8 FFC8
SHA256: root: 07ED BD82 4A49 88CF EF42 15DA 20D4 8C2B 41D7 1529 D7C9 00F5 7092 6F27 7CC2 30C5 and class3: 1BC5 A61A 2C0C 0132 C52B 284F 3DA0 D8DA CF71 7A0F 6C1D DF81 D80B 36EE E444 2869

I checked:
- in all languages and trim sizes are the same fingerprints.
- the fingerprints are the same as they shold be following note 6042
- the address is correct
- the address seams not ne translated (Genève/Geneva/Genf), neither the word "since" in "since 2021".
-- as the address is in French and Geneva is in a French speaking area and French is official language of the world post association, this is absolutely fine for any post service around the world.
-- In the past, the fingerprints did not have a year. Therefore, this part of the form is apparently static and cannot be translated. However, it is useful to indicate the year in order to distinguish old from new forms. The year is essential. If "since" is not translated, I think that is cosmetic and acceptable. The effort to change this is disproportionate.

From my point of view: review passed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1538 [Main CAcert Website] web of trust minor always 2022-01-09 09:49 2022-01-09 09:49
Reporter: alkas Platform: Main CAcert Website  
Assigned To: OS: N/A  
Priority: low OS Version: stable  
Status: new Product Version: 2017 Q4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2017 Q4  
Reviewed by:
Test Instructions: Let the web show lists of certs
Summary: The proposal by Michal (OTRS ticket s20220103.40) to show the last expired certificate
Description: I think that revoked certificates should not appear [in the list of old certs]
because they won't be able to become used again anymore. As to the expired ones,
only the last expired one should appear, in case of will to renew it. Above proposal
will increase the quality of Your services. With regards, Michal
---
It would be possible:
1. to show all old certs only after another click, or
2. displaying the list of valid certs append one lastly expired.
Tags: certificates, client, expired, list, server
Steps To Reproduce: Display the list of issued client or server certificates, then click "Show all certs"
Additional Information: This is a PROPOSAL only.
System Description Production version of the CAcert website
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
971 [CATS.cacert.org] Translation: User Interface minor N/A 2011-08-22 21:16 2022-01-07 20:22
Reporter: Ted Platform:  
Assigned To: Ted OS:  
Priority: normal OS Version:  
Status: needs review Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: User Interface Translation to Spanish
Description: See language file https://svn.cacert.org/CAcert/Education/CATS/lang/spanish.php
Tags: CATS, Translation
Steps To Reproduce:
Additional Information:
Attached Files: spanish_php_revision.diff (19,785 bytes) 2013-01-22 19:09
https://bugs.cacert.org/file_download.php?file_id=315&type=bug
spanish_php_revision_reviewed.diff (19,822 bytes) 2016-05-03 11:50
https://bugs.cacert.org/file_download.php?file_id=418&type=bug
Notes
(0002317)
Ted   
2011-08-22 22:05   
Translation done by Sebastian Klus

Two reviews needed
(0002376)
INOPIAE   
2011-08-31 04:31   
english version can be found here https://svn.cacert.org/CAcert/Education/CATS/lang/english.php
(0002380)
antonio   
2011-08-31 08:42   
Review 1 sent by mail to reporter
(0003714)
chema.alonso   
2013-01-22 19:09   
Uploaded diff file with my revision (spanish_php_revision.diff)

BTW, the original english file ( https://svn.cacert.org/CAcert/Education/CATS/lang/english.ph) includes the word "informationen" (which I believe is in german) at line 156:

define("Statistic_06","user informationen");

I think it should be:

define("Statistic_06","user information");

Regards.
(0005182)
L10N   
2014-12-15 13:40   
Ted, could you ask Antonio and an other spanish speaker to review the diff file? It is waiting for review for nearly two years...
(0005519)
jonas   
2016-05-03 11:51   
I have reviewed the diff file and made some changes. The updated diff file has been uploaded and is named: spanish_php_revision_reviewed.diff

If needed, I will look how to download the original spanish file from the git repository, apply the diff and create a pull request.
(0006090)
L10N   
2021-12-29 21:12   
What happens now after this reviews?
(0006097)
Ted   
2022-01-07 20:22   
The changes of @jonas have been included in the branches bug-971 and testserver. If someone could have another look at it (on the testserver or on https://github.com/CAcertOrg/cats/blob/bug-971/lang/spanish.php ) and confirm that I did this correctly...

If I get that confirmation I'll install the language on the production server.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1444 [Main CAcert Website] source code major always 2018-10-29 20:18 2022-01-05 01:07
Reporter: bdmc Platform: Default  
Assigned To: bdmc OS: any  
Priority: normal OS Version: any  
Status: needs review & testing Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2017 Q4  
Reviewed by:
Test Instructions:
Summary: Update PHP <? tags appropriately
Description: Go through source code and
1. change <?= to <? echo
2. change <? to <?php
3. change each() to foreach()

Tags:
Steps To Reproduce:
Additional Information: Part of bug-1260
System Description Default profile.
Attached Files:
Notes
(0005621)
bdmc   
2018-10-30 04:59   
(Last edited: 2018-11-02 18:05)
mysql.php seems to be missing from source code for bug-1260. ( should be in includes/mysql.php )
After discussion, I found that this file is "hand-created" on the appropriate server when the code is deployed.

All other required files appear to be present, but they may not be found in a test system because references to them are absolute paths.

(0005622)
bdmc   
2018-10-30 05:00   
There are hard-coded references to "http://cacert.org," which can probably cause trouble in development and test systems.
(0005641)
bdmc   
2018-11-02 18:07   
This code is now available for testing.
(0005642)
bdmc   
2018-11-02 18:09   
I found several thousand ( 2500 - 3000 ) instances of required tag changes. Only one instance of each() in the source code that was derived from "release."
(0005643)
bdmc   
2018-11-02 18:10   
The ending "?>" tag, at the bottom of PHP source files can be removed.
(0005644)
GuKKDevel   
2018-11-02 18:16   
I think you shuldn't remove the "?>"tag at the bottom of te PHP source files.

This could cause to assume, some sourcecode could be missing.
(0005645)
bdmc   
2018-11-02 18:23   
Current "best practice" is to omit that tag, because it prevents anything being put into the HTML that is not intended ( extra new lines, extra spaces, etc. ).

On the other hand, I just noted it as something to consider. I did not make this change.
(0005696)
Ted   
2018-12-03 20:53   
Brian, when trying to merge your changes into the test branch I ran into troubles with the "require_once( "general.php" );" in www/index.php which I still do not understand.

First of all, the path does not look right when compared to the other require_once statements, but even with the path a "not found" error is reported.

Why did you add this line? Other files seem to include require_once("../includes/lib/general.php") or require_once("../includes/mysql.php"), general.php from include seems only to be used by files which are currently not active in the web page...
(0005697)
bdmc   
2018-12-03 21:36   
I'm sorry, Ted. That was added for testing, and I forgot to remove it afterwards. Done now. general.php is in includes and includes/lib.
(0006089)
L10N   
2021-12-29 21:04   
How can I test that?
(0006091)
bdmc   
2022-01-05 01:07   
Test procedure for this should be:

Edit php.ini and set "short_open_tag = Off"

Attempt to run the code. If there are any short tags "<?" remaining, they will appear as errors.

The abbreviation "<?=" will still be allowed, so if you want to test for ( and eliminate ) those, it will require a grep or other text search.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1535 [Main CAcert Website] certificate issuing minor have not tried 2021-11-11 20:49 2021-11-28 22:10
Reporter: L10N Platform: Main CAcert Website  
Assigned To: OS: N/A  
Priority: normal OS Version: stable  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: CSRF Token not being validated
Description: I'm Monsef djouadi a security researcher from Algeria , i created an account in your website and i've been
And suddenly i found a security vulnerability which is CSRF Token not being validated in request of editing account which leads to account takeover
I hope you fix that vulnerability to make web a safe place.
Tags:
Steps To Reproduce:
Additional Information: Transmission of Bug submitted by Facebook.
System Description Production version of the CAcert website
Attached Files:
Notes
(0006085)
L10N   
2021-11-28 22:09   
Contribution by Ted on the mailing list:

probably it would make sense to ask for a detailed step-by-step procedure on how to reproduce this problem. The current description is quite vague so it's hard to find the place to look for in detail (or does anyone already know?).

I strongly assume that CSRF refers to Cross-Site-Request-Forgery, so probably a specifically prepared web page is needed to exploit this vulnerability. If such a web page could be provided it would greatly help in analysis.
(0006086)
L10N   
2021-11-28 22:10   
Answer on Facebook / asking for more information:

Hello Moncef, I talked with one of our ingeneers. He said, it would make sense to send us a detailed step-by-step procedure on how to reproduce this problem. (you may write in English or French, just what is better for you.) The current description is or him quite vague so it's hard to find the place to look for in detail.

He strongly assume that CSRF refers to Cross-Site-Request-Forgery - is he right? So probably a specifically prepared web page is needed to exploit this vulnerability. If such a web page could be provided it would greatly help in analysis.

Thank you for telling us about this issues and beeing part of the community.

Thank you and best regards,


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1482 [Main CAcert Website] General block N/A 2020-06-27 09:30 2021-09-01 22:49
Reporter: SaT Platform: Default  
Assigned To: jandd OS: any  
Priority: urgent OS Version: any  
Status: fix available Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Limit validity period of new HTTPS certificates to one year
Description: According to the German article from Heise (1), most browser manufacturers will not accept HTTPS certificates anymore after September 1, 2020, if they have a validity period longer than one year. This article mentions other sources from Apple (2) and Google (3) regarding this decision.

CAcert should respect this constraint when issueing SSL server certificates. It could be hard-coded, or the user may be able to select if the certificate has a validity period of e.g. 6 months, 1 year or 2 years.

(1) https://www.heise.de/news/Browser-Hersteller-verkuerzen-Zertifikats-Lebensdauer-auf-1-Jahr-4796599.html
(2) https://support.apple.com/en-us/HT211025
(3) https://chromium.googlesource.com/chromium/src/+/ae4d6809912f8171b23f6aa43c6a4e8e627de784
Tags:
Steps To Reproduce:
Additional Information:
System Description Default profile.
Attached Files: 0001-Reduce-the-lifetime-of-certificates-to-366-days.patch (1,089 bytes) 2021-01-31 11:35
https://bugs.cacert.org/file_download.php?file_id=493&type=bug
Notes
(0005894)
L10N   
2020-06-27 13:11   
I have read the comments at Heise and come to the following conclusion:
1. we have to reduce the validity period from September 1 to 398 days (or 396 days - one day margin and every four years leap year)
2. if feasible, offer the validity period at the same time - otherwise later if possible - selectable:
As SaT says: 6/12 months (for web), but also 2/3/ev.5 years for other applications.
See among others the following article at Heise:

https://www.heise.de/forum/heise-online/Kommentare/Browser-Hersteller-verkuerzen-Zertifikats-Lebensdauer-auf-ein-Jahr/Als-ob-nur-Webserver-Browser-Zertifikate-verwenden/posting-36927599/show/
(they write about smtp, imap, ftp, ldap, xmpp, stunnel, and others)

The selection (e.g. radio button) must clearly state "for all purposes, incl. https" or "not suitable for websites/https" next to the duration.
(0005900)
Ted   
2020-08-09 09:25   
I just had a look at Apple's page cited above. There the Statement is "This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS."

Chromium's statement is "Enforce publicly trusted TLS server certificates ...", which is not as specific as Apple's, but could be interpreted the same way...
(0005936)
jandd   
2021-01-01 05:15   
This is actually a software development issue because it needs changes to at least the signer client that currently determines the validity period of our certificates.
(0005942)
bdmc   
2021-01-07 22:45   
jandd, have you created a Git branch for this yet?
(0005949)
jandd   
2021-01-31 11:34   
I just created https://github.com/CAcertOrg/cacert-devel/pull/23 for this
(0005950)
jandd   
2021-01-31 11:35   
Patch from the PR attached
(0005953)
Ted   
2021-02-01 21:43   
I'm afraid that this change has to be approved in the policy group.
The current CPS explicitly states a validity period of 24 months for assured members. The CPS can only be changed by the policy group, and we (as the software development group) are not allowed to install changes contradicting the CPS!
(0006084)
L10N   
2021-09-01 22:49   
That's an important hint, but I don't think it's an obstacle. If we offer our members 48 months, but optionally also shorter (longer?) terms, it should be possible.

( ) 5 years (not suitable for websites/https)
( ) 2 years (not suitable for websites/https)
( ) 1 year (for all purposes, incl. https)
( ) 6 months (for all purposes, incl. https)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8 [Main CAcert Website] GPG/PGP major always 2005-09-02 01:52 2021-08-26 11:55
Reporter: roe Platform:  
Assigned To: Sourcerer OS:  
Priority: normal OS Version:  
Status: needs review Product Version: 2005  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2015 Q1  
Reviewed by:
Test Instructions: Try to sign PGP keys with various variants of the name on record.
Summary: Normalization of special characters when comparing names
Description: There is a flaw in the name matching algorithm, eg. when matching the names on GPG key UIDs with the name in the CAcert database: Umlauts are not translated or normalized. The German Umlaut "ö" (o with two dots) is exactly the same as the two letter combination "oe", and the same goes for ü/ue and ä/ae.

So for instance, I have "Röthlisberger" on record with CAcert, while my GPG keys spell "Roethlisberger" (less charset hassle when using the oe form). I cannot add my perfectly valid GPG keys to my CAcert account because "Röthlisberger" does not match "Roethlisberger".

Lots of people with weird characters in their names prefer to sometimes use a plain 7bit ASCII version of their name, in order to avoid encoding hassle, and that seems to be perfectly legitimate and should be fully supported by CAcert.

Please fix the name matching algorithm to cather for German Umlauts and treat öäü the same as oeaeue and oau. Otherwise people with special characters in their names will not be able to use some features of CAcert.

There are probably similar problems with many other European languages, like French accents (éàèç) or nordic special letters.

The only alternative is to remind people that they should choose the same version of their name like they use on GnuPG keys and as they want the name to appear in SSL/TLS certs. (And, give people like me some option to change my name in the CAcert database to the 7bit US ASCII representation)
Tags:
Steps To Reproduce:
Additional Information: The beginning of a special character translation table:
ö = oe = o
ü = ue = u
ä = ae = a
é = e
è = e
à = a
ç = c

(there are many more in other areas of the world -- these are just the ones which are common in Switzerland)
Attached Files:
Notes
(0000001)
roe   
2005-09-02 06:18   
Actually, it just says "No emails found on your key" now when I upload my (rather large) main key. I had to strip my key down to its bare essentials (just non-revoked uids and only self-sigs) in order to get the error message: "No suitable name combination could be matched from your PGP/GPG keys to what we have in the database ('Daniel Roethlisberger')"
(0000333)
duane   
2006-08-08 06:12   
Is anyone able to propose a fix/patch for this at all?
(0001376)
stefanb   
2009-04-20 10:46   
(Last edited: 2009-04-28 05:35)
Character normalization table for Slovenian language:
?=C
?=c
Ž=Z
ž=z
Š=S
š=š
?=C
?=c
?=Dz/Dj
?=dz/dj
(it seems Manitis has problems with non-western encodings, so here's the link to those, and other characters: http://www.slovo.info/testuni.htm )

Alternative normalizations in the last two lines and rules depending on language would mean that names (first, last, middle, suffix) would need to entered by user, and confirmed by assurers in order to be made promoted into valid name variations.

My real name is "Štefan", but it is legal to write it as "Stefan" if there are (or might be) technical obstacles. I registered with "Stefan", because even government issued x509 certificates are normalized this way (even if "Stefan" is similar, but different valid name).

I warned my assurers about the difference in case we need to reassure. It says "Štefan" on CAP forms.

One day I'd love to get my real name into the certificates, but first just for testing purposes to make sure no important tool is terribly broken, and with always available option to revert to normalized name.

It would also be great if users could choose which variant of their name would be put into the client certificate, so they can have 2 name variants at the same time.

In my PGP key i have both names, but only the key with "Stefan" was signed by CAcert.

(0003485)
Werner Dworak   
2012-12-20 17:54   
AFAIK there is no real solution possible. You can only create a second name in the GPG that matches the CAcert name, or you change the CAcert name (omit non-ASCII or non-ANSI character) to the GPG name.
(0004831)
felixd   
2014-06-15 08:53   
Is it now possible with www/utf8_to_ascii ?
(0005218)
BenBE   
2015-01-03 02:16   
See bug 0001354 for the bug fix as this was done in combination.
(0005226)
Eva   
2015-01-06 21:18   
The tests for 1354 are exactly the same as for this bug. So tests for one bug should cound for both, as the relevant code is the same as well.
(0005344)
felixd   
2015-03-03 21:13   
I did a test of 0001354 that had the same test instructions. => Test PASSED
(0005347)
Eva   
2015-03-03 21:15   
I did a successfull test at 2015-01-20 22:11 as eneredd in bug 1354
(0005348)
Eva   
2015-03-03 21:16   
As there are two successfull tests, please do your reviews
(0006082)
alkas   
2021-08-26 11:55   
Probably needs to be solved with move the DB coding to UTF-8


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1360 [Main CAcert Website] GPG/PGP major always 2015-01-16 12:25 2021-08-26 11:45
Reporter: wytze Platform:  
Assigned To: Eva OS:  
Priority: normal OS Version:  
Status: needs review Product Version: 2015 Q1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2015 Q1  
Reviewed by: BenBE
Test Instructions: See Steps to Reproduce
Summary: signing of gpg keys stalls due to missing directory, and also causes delays for X.509 certificate signing and revocation
Description: The signing of gpg keys by the CAcert application may stall due to a missing directory for storing the signed keys.

The current code allocates a new subdirectory for every 1000 signed keys, but the code to create this new subdirectory is missing for the gpg case (it is present though for the X.509 case). The CommModule client.pl code attempts to write the signed gpg key to a file in this non-existing directory and fails, which leads eventually to an error message: "Could not find the issued gpg key.". However, the same request will be retried over and over without limit, causing delays for all signing requests, including X.509 certificates.
Tags:
Steps To Reproduce: Remove empty subdirectories under /home/cacert/www/crt/gpg.
Then issue more than 1000 gpg signing requests, so somewhere along the line a new subdirectory is needed.
Additional Information: As a work-around, a number of subdirectories have been pre-created on the production server, so this failure will not occur again anytime soon, even without a code fix.

The problem is in this code fragment from CommModule/client.pl:

sub HandleGPG()
{
  my $sth = $dbh->prepare("select * from gpg where crt='' and csr!='' ");
  $sth->execute();
  my $rowdata;
  while ( $rowdata = $sth->fetchrow_hashref() )
  {
    my %row=%{$rowdata};

    my $prefix="gpg";
    my $short=int($row{'id'}/1000);
    my $csrname = "../csr/$prefix-".$row{'id'}.".csr";
    $csrname = "../csr/$prefix/$short/$prefix-".$row{'id'}.".csr" if($newlayout);
    SysLog("New Layout: "."../csr/$prefix/$short/$prefix-".$row{'id'}.".csr\n");

    #my $crtname = "../crt/$prefix-".$row{'id'}.".crt";
    my $crtname=$csrname; $crtname=~s/^\.\.\/csr/..\/crt/; $crtname=~s/\.csr$/.crt/;
    SysLog("New Layout: $crtname\n");

The following code should be inserted before the last line:

    my $dirname=$crtname; $dirname=~s/\/[^\/]*\.crt//;
    mkdir $dirname,0755;

Attached Files:
Notes
(0005242)
wytze   
2015-01-16 12:28   
See https://lists.cacert.org/wws/arc/cacert-systemlog/2015-01/msg00015.html
(0005244)
BenBE   
2015-01-16 17:57   
The change was performed slightly different than suggested to remove a minor code duplication in the process and also ensure all paths are built based on the directory name.
(0005254)
felixd   
2015-01-20 23:02   
Test:

I issued enough pgp signatures for the pgp-signer daemon to require a new directory (around 200).
I was told that the signer created that new directory.

Test is therefore PASSED.
(0005256)
INOPIAE   
2015-01-21 20:39   
I create certs for client and org server certificates.
For both certs the new directory was created.

=> ok
(0006081)
alkas   
2021-08-26 11:45   
Reviewed in 0001360:0005256, but not closed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1317 [Main CAcert Website] GPG/PGP major always 2014-10-29 00:02 2021-08-26 11:41
Reporter: janmaco Platform:  
Assigned To: Eva OS:  
Priority: normal OS Version:  
Status: needs review Product Version: 2014 Q3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2015 Q1  
Reviewed by: BenBE
Test Instructions: Try to sign a mail address with a plus sign in it.
Summary: Weak email sanity check when adding a new PGP key
Description: I tried to sign a PGP key with an email address containing a + (like test+a@example.tld). Using such an e-mail results in an error (No valid uid).
Tags:
Steps To Reproduce: Create a PGP key with an email address containing a '+' -> paste it to the "Add PGP key" form
Additional Information: A cause may be located in incomplete regexes;
www/gpg.php:381
 if (preg_match("/<([\w.-]*\@[\w.-]*)>/", $bits[9],$match)) {
                    //echo "Found: ".$match[1];
                    $mail = trim(gpg_hex2bin($match[1]));
                }
Attached Files:
Notes
(0005237)
janmaco   
2015-01-14 10:59   
(Last edited: 2015-01-14 11:17)
I have a patch for this bug here: https://github.com/yellowant/cacert-devel/commit/1439176e62ab63d6ab522b07ca18213e56c24bf4

(0005305)
Eva   
2015-02-03 21:25   
I created a pgp key for the address 1317+asterix@acme.com and added it to the account.

The key was signed. -> ok
The key contained the signature -> ok
The key contained the correct name and email address -> ok
The key was displayed correctly in the "view" overview for pgp keys -> ok

=> ok

(I did not test other special characters as only "+" seems to be added)
(0005342)
felixd   
2015-03-03 21:09   
I got a PGP key signed with an email address containing a "+". Keys with an incorrect email address still get rejected.

=> PASSED
(0005345)
Eva   
2015-03-03 21:14   
As there are two successfull tests, please do your review(s)
(0006080)
alkas   
2021-08-26 11:41   
The path proposed by 0001317:0005237 is NOT performed (on the testserver only?)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1461 [Blog] text always 2019-04-26 20:53 2021-08-25 13:41
Reporter: L10N Platform: Iiggg  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Hatchek, etc. not displayed
Description: zkouškou" is not displayed. Letters with hatchek or a cercle about an u are replaced with "?".
Tags: blog, unicode
Steps To Reproduce: Put some czech text in the text window. Press the preview button or the publish button. Accents will be replaced by "?".
Additional Information: The example shown in the uploaded pictures was written in LibreOffice, saved as png-picture and published as picture, not as text.
Attached Files: CAcertCATSCzech.png (223,664 bytes) 2019-04-26 20:53
https://bugs.cacert.org/file_download.php?file_id=466&type=bug
Screenshot_2020-08-08 Wikipedie, otevřená encyklopedie.png (96,861 bytes) 2020-08-07 22:11
https://bugs.cacert.org/file_download.php?file_id=476&type=bug
Screenshot_2020-08-08 Add New Post ‹ CAcert Blog — WordPress.png (73,037 bytes) 2020-08-07 22:11
https://bugs.cacert.org/file_download.php?file_id=477&type=bug
Screenshot_2020-08-08 lánek týdne.png (67,158 bytes) 2020-08-07 22:11
https://bugs.cacert.org/file_download.php?file_id=478&type=bug
Notes
(0005883)
jandd   
2020-05-12 20:00   
An idea: maybe the charset of some database tables is not utf8mb4. The database has been migrated from older versions of Wordpress. Needs to be checked by an admin (Dirk or me) we should also check whether wordpress sends the correct encoding in the Content-Type header.
(0005885)
egal   
2020-05-16 20:35   
The "older" tables are "latin1_swedish_ci":

| wp_commentmeta | utf8mb4_unicode_ci |
| wp_postmeta | latin1_swedish_ci |
| wp_terms | latin1_swedish_ci |
| wp_term_relationships | utf8mb4_unicode_ci |
| wp_usermeta | latin1_swedish_ci |
| wp_users | latin1_swedish_ci |
| wp_termmeta | utf8mb4_unicode_ci |
| wp_comments | latin1_swedish_ci |
| wp_posts | latin1_swedish_ci |
| wp_term_taxonomy | latin1_swedish_ci |
| wp_links | latin1_swedish_ci |
| wp_options | latin1_swedish_ci |

Wordpress itself uses utf-8:
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

as wordpress was updated in april 2020, please test again ...
(0005899)
L10N   
2020-08-07 22:11   
I tested with an article of the main page of cs.wikipedia.org (pic 1 Wikipedia) and copy pasted it into the blog (pic 2 Ad New Post), then clicked on preview (pic 3 lánek). The result is as follows: In Wikipedia all accents/hatcheks are displayed. In the "new post section", they are displayed as well - only in the title not. In the preview are still "?".

You can check in the 2nd line "Arpodvocu" (u with circle on it -> ?), "peceneszke" (c and e with hatchek -> ? [s and z with hatchek is displayed]),


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1441 [test.cacert.org] test.cacert.org block always 2018-06-19 11:28 2021-08-25 13:40
Reporter: GuKKDevel Platform: Test CAcert Website  
Assigned To: wytze OS: N/A  
Priority: immediate OS Version: Test  
Status: solved? Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: umlauts are not stored/displayed correctly in Testsystem
Description: Enter a name with an umlaut into https://test.cacert.org/index.php?id=1.

after verifying with test-mgr login and view accounts data.

umlaut is dissappeared and some other chars are shown.

therefore if transferred to original, no CAP-verification is possible, gpg-signing is not possible.
Tags: browser, certificates, diacritic, legal name, names, organization name, PGP, server certificates
Steps To Reproduce: Enter a name with an umlaut into https://test.cacert.org/index.php?id=1.

after verifying with test-mgr login and view accounts data.

umlaut is dissappeared and some other chars are shown.
Additional Information:
System Description Test version of the CAcert website
Attached Files:
Notes
(0005601)
egal   
2018-06-19 18:32   
moved issue to project "test.cacert.org" as it not infrastructure-related
(0005602)
egal   
2018-06-19 19:29   
This issue happens in productive system, too:

Created a user with umlauts to my own domain, did NOT click on the confirmation link, but checked this user via support console: Umlauts are "broken".
(0005606)
wytze   
2018-06-22 13:04   
A bug was found in the PHP5 configuration of the CAcert webdb server as
described in https://bugs.cacert.org/view.php?id=1441: "umlauts are not
stored/displayed correctly". This bug actually affects all handling of
non-latin characters by the CAcert application code, and was introduced
by the upgrade of the CAcert chroot application environment from Debian
Wheezy to Debian Jessie on April 16, 2018.

Starting with PHP 5.6, PHP's default character set is set to UTF-8.
This is not what the current CAcert application code expects, so we
need to overrule it with the earlier default "iso-8859-1".
Note that Debian Wheezy contained PHP 5.4.45, while Debian Jessie
contains PHP 5.6.33.

Affected files:
   /home/cacert/etc/php5/mods-available/cacert.ini
   /etc/php5/mods-available/cacert.ini
   /root/chroot/mkchrootenv (also in SVN)

The same changes have been applied to the test.cacert.org and test2.cacert.org
test servers.

Note that new accounts created between April 16, 2018 and June 22, 2018,
may have been affected by this issue. This will be reported as an incident
to support@cacert.org for arbitration and possible further investigation.

See also https://lists.cacert.org/wws/arc/cacert-systemlog/2018-06/msg00002.html


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1419 [Main CAcert Website] website content minor always 2016-12-19 12:23 2021-08-25 13:39
Reporter: Ludovic Platform: Main CAcert Website  
Assigned To: OS: N/A  
Priority: normal OS Version: stable  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Issue with displaying "é" as é in "Client Certificates - View all certificates"
Description: For URL https://www.cacert.org/account.php?id=5
In the column Revoked the text "Not Revoked" is displayed "Non révoqué" instead of 'Non révoqué" for French translation.

The HTML source code is: "<td class="DataTD">Non r&eacute;voqu&eacute;</td>"
But should be "<td class="DataTD">Non révoqué</td>"

The "é" is correctly converted to "é" but then the "&" is translated to "&".
Tags:
Steps To Reproduce: Switch to French in the default language (URL https://www.cacert.org/account.php?id=41)
Then display the list of user certificats (URL https://www.cacert.org/account.php?id=5)
Additional Information: The HTML page uses content="text/html; charset=utf-8" so it should be possible to directly use the "é" in utf-8.
System Description Production version of the CAcert website
Attached Files: cacert.png (210,963 bytes) 2016-12-19 12:23
https://bugs.cacert.org/file_download.php?file_id=419&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1402 [CATS.cacert.org] Translation: Content text always 2015-09-21 18:14 2021-08-25 13:39
Reporter: alkas Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 8  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: A comment on deployed Czech translation of the "Assurer's Challenge" test
Description: The following is a part of the Test and Results web (generated) pages - head:
meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"
The code should not be iso-8859-1, for this text containing non-ISO-8859-1 characters this should be Windows CP-1250, as the text is so coded. Or, possibly later, Unicode UTF-8 should be used. There is possibility in a browser to change coding, but it is of no use for common end users.
Tags: CATS, diacritic, Translation
Steps To Reproduce: Select test "Výzva zaručovatele (CZ)" and try to answer the questionnaire. It works OK except minor misscoding of some questions. The browser used was IE10 on Windows 8.0.
Additional Information: If you realize to change coding after you have answered some questions, all your answers will be cleared after the change.
Also the answers "true", "false" are English, not Czech. Possibly it will change after the Czech user interface will be deployed.
System Description Test version of the CAcert website
Attached Files: Výzva_zaručovatele_.txt (47,366 bytes) 2015-10-01 14:13
https://bugs.cacert.org/file_download.php?file_id=409&type=bug
Notes
(0005463)
alkas   
2015-10-01 14:17   
Added file with the test in Czech. The file contains no information about correct answers.
(0005733)
Ted   
2019-01-13 14:53   
(Last edited: 2019-01-13 14:54)
The charset in Content-Type is used by the browser only to decide which characters may be sent unencoded.

The test still supports the whole UTF charset, but non-iso-8859-1 characters are transmitted as HTML entities (for example something like & # 367;), which is perfectly OK for the browser (and the database).

So, yes, I would prefer to have the pages being announced as using utf-8 charset, but IMHO this would only change the data management in the backend, and have no effect on the user.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1401 [Main CAcert Website] account administration major always 2015-09-09 07:08 2021-08-25 13:39
Reporter: wytze Platform: Default  
Assigned To: BenBE OS: any  
Priority: high OS Version: any  
Status: new Product Version: 2015 Q3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2015 Q3  
Reviewed by:
Test Instructions:
Summary: Names containing non-ascii characters are displayed incorrectly on the website
Description: This (anonymized) support request was received by critical-admin@cacert.org:

-------------------------------------------------------------------------------
My email: xxxxx
My first name: xxxxx
My middle name: xxxxx
My last name: Żxxxxx

However, my last name at https://www.cacert.org/account.php?id=13 (ie.
My Details View/Edit) is 'Żxxxxx'

Where 'Ż' is a decimal html encoding of 'Ż'.

Unicode Decimal Code Ż

Symbol Name:Latin Capital Letter Z With Dot Above
Html Entity:
Hex Code:&#x17b;
Decimal Code:Ż
Unicode Group:Latin Extended-A

Could this be fixed in the database to be 'Żxxxxx' (presumably
correctly UTF-8 encoded)?
-------------------------------------------------------------------------------

critical-admin@cacert.org answered with:

-------------------------------------------------------------------------------
The database contains the Ż encoding, which I believe to be correct
(according to the way the CAcert application code works in general).
The display is indeed not correct, which IMHO opinion is caused by a code
change made on 7 June 2014, in particular the change to pages/account/13.php,
which is now passing the database values through the sanitizeHTML() function.
This function is transforming the & to &, causing the first character of
this user's name to be passed to the browser as &0000379; which will result
in the bad display experienced by this user.

I suggest to file an issue on bugs.cacert.org for this problem, it requires
a (set of) code change(s) to fix it.

FYI: I have attached the checkin notification containing the offending
change -- unfortunately it was rather complex and large.
-------------------------------------------------------------------------------

The checkin notification mentioned above can be found at:

https://lists.cacert.org/wws/arc/cacert-systemlog/2014-06/msg00005.html

Unfortunately, the suggestion to report this issue on bugs.cacert.org was not followed up by CAcert Support. Hence critical-admin@cacert.org does it now.
Tags:
Steps To Reproduce: Register a name containing a special character like Ż and observe the way it is displayed on https://www.cacert.org/account.php?id=13
Additional Information:
System Description Default profile.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1398 [CATS.cacert.org] Translation: User Interface minor N/A 2015-08-21 21:24 2021-08-25 13:38
Reporter: Ted Platform:  
Assigned To: Ted OS:  
Priority: normal OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: User Interface Translation to Czech
Description: Initial language file provided by Aleš
Tags: CATS
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0005453)
Ted   
2015-08-21 21:53   
The czech translation uses non ISO-8859-1 characters.

This could be the occasion to move CATS from ISO-8859-1 to UTF-8 encoding, and I'll consider that job as part of this bug.
(0005737)
Ted   
2019-01-14 22:21   
For now, the "dangerous" characters of the translation have been replaced by HTML encodings.

The bug branch has been merged into the testserver branch, which is now installed on the testserver, so it is now possible to select czech language for the user interface!

Please test the translation, though I'm still evaluating if it is possible to move to UTF-8 encoding completely.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1389 [Main CAcert Website] misc minor always 2015-07-21 19:40 2021-08-25 13:38
Reporter: StefanT Platform:  
Assigned To: BenBE OS:  
Priority: urgent OS Version:  
Status: solved? Product Version: 2015 Q3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2015 Q3  
    Target Version: 2015 Q3  
Reviewed by: NEOatNHNG, BenBE
Test Instructions: https://bugs.cacert.org/view.php?id=1389#c5421
Summary: Wrong encoding for mails sent with function sendmail()
Description: While preparing an event mailing in Danish there were problems to properly transcript Danish to ASCII. Thus sending full UTF-8 is required. When testing the mailing it was found that special characters outside the ASCII range were encoded wrong, even when UTF-8 was explicity set in the mailing script.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0005420)
felixd   
2015-07-21 20:28   
A patch is available here: https://github.com/yellowant/cacert-devel/tree/bug-1389
(0005421)
felixd   
2015-07-21 20:28   
Test instructions:
Test various events where mail is sent to the user. Make sure the first name in the account contains a special character. Examples for functions to test include:
- Mail to assurer
- Mail to assuree
- Changing primary email address
- Changing password
- Changing password from SE console
- Looking at secret questions
- Looking at secret questions from SE console
- Disputing email and domain

Test any other event where you know that a special character is used while sending a mail.
Also check that sending mails in languages other than English (e.g. German, Finnish, Russian, Swedish, ...) are displayed correctly. BEWARE: The test management server uses UTF-8 by default passing the mail through without re-encoding it according to the Content-Type header. In case of doubt ask someone with access to the raw mail files to check/for a transcript of the raw mail.
(0005422)
StefanT   
2015-07-22 16:38   
Scenario:
New User: karl.coyote@looney.org Pass: Testing12
Link in Email: http://cacert1.it-sls.de/verify.php?type=3Demail&emailid=3D305465&hash=3D31=bbeb7759707a89a9a56c5677a9b0b5
At my try to acknowledge the Account i became this Error:
"Fehler!
Parameter fehlen. Bitte benutzen Sie die komplette URL." (in german of course)
(0005424)
felixd   
2015-07-22 18:53   
yes, this problem is due to the test management server not being able to display "quoted-printable"-content correctly.

The link was initially:
http://cacert1.it-sls.de/verify.php?type=email&emailid=305465&hash=31bbeb7759707a89a9a56c5677a9b0b5

Where there was a line break after the "hash=31" due to the line being too ling. The other "=3D"s are literal "="s. I am pretty sure that an ordinary email client will display the link so that it can be copied out correctly.
(0005425)
BenBE   
2015-07-22 19:28   
Please see 0001390 for the explanation. Basically just like felixd said: The test management system is kinda broken in regards to display of mails.

ATM only a nl2br is performed, thus you need to decode the quoted printable in your head ;-) Or rather: If the decoding indicates proper UTF8, the mail is sent correctly ;-)
(0005443)
INOPIAE   
2015-08-09 15:12   
The problems from the test management server are fixed.
(0005447)
StefanT   
2015-08-11 20:38   
The Test Mail (Danish Part) on Testaccount "paul.panter@pink.org":
*****
     

Read Mail
[Danish]
Gennem det sidste års tid er der sket mange ændringer hos CAcert. Mange
mundtlige regler er blevet skrevet ned i politikker. Nye procedurer (f.eks.
Assurer Challenge) og forpligtelser (f.eks. CAcert Community Agreement) har
set dagens lys.
Assurandør trænings events (ATE) forsøger at udbrede disse informationer.
- Hvad mangler på den gamle CAP formular?
- Hvorfor skal jeg huske R/L/O?
- Hvad kan du gøre hvis en person fremviser ID dokumenter jeg ikke
kender?
Disse og flere spørgsmål vil blive besvaret under en Assurandør trænings
event (ATE)
Yderligere, træner man på ATE, hvordan man verificere og kontrollere
verificeringer for at måle kvaliteten af verificeringsprocessen i det
daglige. Der er en del fejl, som er nemme at falde i. Assurandører får
mulighed for at se disse fejl og hvordan man undgår dem.
Som IanG sagde: ATE eller Assurandør Træningens events er klart anbefalet
til alle assurandører og indeholder dele som hjælper direkte med vores
godkendelseskontrol. Kom og find ud af hvordan du også kan hjælpe.

Den næste event, som afholdes i dit område er:
- Søndag d. 20. September 2015
- Kl. 10:00 – ca. 17:00
- ShowIT Media
- Slotsbryggen 14 A-D
- 4800 Nykøbing F.
- Denmark

BEMÆRK: eventen foregår på engelsk
Detaljerne om eventen og programmet kan findes på:
Wiki [https://wiki.cacert.org/Events/2015-09-20-ATE-DK-Nykobing]
Blog [tbd]
Du kan tilmelde dig ved at besvare denne mail og i emnet feltet skrive: “I
will attend the ATE-Nykobing”
Event teamet ser frem til din deltagelse
Kontakt: events@cacert.org
*****

The Mail is displayed correct with all special Characters => OK
(0005450)
INOPIAE   
2015-08-20 18:18   
Looking at the event mail sent on Aug 9th
the danish special characters are correst displayed. Unfortunately there were no German special charcaters in the mail body. So there is no proof from there.

=> ok
(0005451)
INOPIAE   
2015-08-20 18:19   
please as we have two success full tests
(0005454)
NEOatNHNG   
2015-08-23 15:55   
Patch looks OK.

One remark though: The non-utf8 case is not used anywhere in the system now, and probably it won't work because HTML entities are encoded to utf8 while the content type says it's latin1. ==> non-utf8 case should be removed IMHO

The only place where the latin1 variant was used before, were the mailing scripts and there it especially made no sense. That was probably the reason why special characters were broken in the mailing scripts. Now the parameter they set gets interpreted as if they wanted utf8 support which makes sense and should work.
(0005458)
BenBE   
2015-08-26 06:43   
Patch forwarded to crit.
(0005459)
wytze   
2015-08-28 15:43   
The fix has been installed on the production server on August 28, 2015. See also:
https://lists.cacert.org/wws/arc/cacert-systemlog/2015-08/msg00007.html


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1354 [Main CAcert Website] source code minor sometimes 2015-01-02 14:01 2021-08-25 13:38
Reporter: BenBE Platform:  
Assigned To: BenBE OS:  
Priority: high OS Version:  
Status: needs review Product Version: 2015 Q1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: BenBE
Test Instructions: 0001354:0005216
Summary: Problems with diacretics and non-latin1 characters
Description: Based on a mail report the following issue was found:

When trying to sign a PGP key with diacretics in the name or other non-latin1 characters the name is not accepted by the software. This is due to the way data is encoded in the database.

Further investigations showed several instances of double-escaping of the displayed name throughout the software.
Tags:
Steps To Reproduce: Register an account with non-latin1 characters in it. Throughout the software you'll notice HTML entity encoding for the name.
Additional Information: The storage in the database is as follows:
- Everything in latin1 is stored AS IS.
- Everything outside latin1 is stored as &# 1234; with 1234 being the decimal code point of the character.
Attached Files:
Notes
(0005214)
BenBE   
2015-01-02 14:24   
A priliminary patch has been applied on the test server which for now ignores the issue mentioned in 0000008 but is written so the necessary changes from there could be easily incorporated. Also this ignores simplifications of the name, thus "Mueller" instead of "Müller" in the account is not yet accepted when signing. Such simplifications are subject to 0000008 and others.
(0005215)
BenBE   
2015-01-03 01:53   
A simple set of transliteration rules has been added. Please see the source for which exactly as the list is a bit longer.

Please note that Müßli can be written Muessli or Mussli, but neither Mußli nor Müssli are acceptable. Thus as given in the Practice on Names a transliteration always has to be complete.
(0005216)
felixd   
2015-01-03 02:12   
(Last edited: 2015-01-03 02:15)
Test instructions:

create an account with strange characters in his name (ä,ö,ü,ß and many more).

try to transliterate them all and add this as an id to your gnupg key.
signing this id should work.
signing any other ids (especially ones where the transliteration is not complete) should fail

(0005217)
felixd   
2015-01-03 02:15   
Test:

An account named "ÞÞ ÀÆÐÒÓÔÕÖØÛÜÝ" had

- thth aaedjoooooouuey signed
- thth aaedoooooouuey not signed
- Þth aaedjoooooouuey got not signed

Test was therefore PASSED
(0005224)
maze   
2015-01-03 20:25   
Test now passes.

Created an account with first/middle/last name of "Maciej" "Arthur" "Żenczykowski".

My last name now displays correctly in "My Details - View/Edit" (both places last name shows up in account history looks good too).

Signing a gpg key now passes UID verification.

Key used:

$ gpg2 -K AB316850
sec 4096R/AB316850 2010-01-22
uid Maciej Arthur Żenczykowski (Personal)
<zenczykowski@gmail.com>
ssb 4096R/FA401B8D 2010-01-22

Blob to sign generated via:

$ gpg2 --export --export-options export-minimal --armor AB316850
(0005235)
Eva   
2015-01-13 22:25   
I created an account with below data and got it assured to 100 points.
first name: Äüößčéěęæ
last name: ŇÁÝŘŁŒŸÇ
no middle name and no suffix
email: bug1354es@acme.com

I created a pgp key with UID: Äüößčéěęæ ŇÁÝŘŁŒŸÇ <bug1354es@acme.com>

And tried to get it signed (without a comment)

The key was not accepted.

=> fail
(0005236)
BenBE   
2015-01-14 00:46   
(Last edited: 2015-01-14 00:58)
A note on Eva's test using account bug1354es (ÄT) acme {DOT} com:

While conversion from UTF-8 of the name "Äüößčéěęæ ŇÁÝŘŁŒŸÇ" (from GnuPG) is escaped properly as
string(103) "&#196;&#252;&#246;&#223;&#269;&#233;&#283;&#281;&#230; &#327;&#193;&#221;&#344;&#321;&#338;&#376;&#199;"

the same string when fetched from the database (ISO-8859-1) is escaped only partially:
string(93) "&#196;&#252;&#246;&#223;&#269;&#233;&#283;&#281;&#230; &#327;&#193;&#221;&#344;&#321;ŒŸ&#199;"


There seems to be a PHP bug though ???

(0005249)
Eva   
2015-01-20 21:50   
I performed the same test as at 5235. I entered "Äüößčéěęæ ŇÁÝŘŁŒŸÇ <bug1354es@acme.com>" as comment for the key.
It is working now.
-> ok
The result page showed all characters correctly.
-> ok
I performed a pgpdump with the new key and it did look good (with correct names).
-> ok
I went to the view pgp keys page. The key was there, but the comment for the key was missing.
-> fail
(0005251)
Eva   
2015-01-20 22:11   
I did the same as 5249.
Everything was displayed / entered correctly.
=> ok
(0005341)
felixd   
2015-03-03 21:03   
I named myself "Äüößčéěęæ ŇÁÝŘŁŒŸÇ" and got a gpg key with that name signed.

Additionally I re-executed 0001354:0005217 and everythig was still as expected

=> PASSED
(0005349)
Eva   
2015-03-03 21:17   
as there are two positive tests, please review


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1311 [Main CAcert Website] account administration minor N/A 2014-10-04 09:49 2021-08-25 13:37
Reporter: Ruel Print Platform: Default  
Assigned To: OS: Windows 7  
Priority: normal OS Version: Ultimate  
Status: new Product Version: 2014 Q4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: The check about email during email dispute works incorrect
Description: Taken from Ticket s20141001.32
I observed that there was an email disput that fires this mail:
Someone has just attempted to dispute this email 'someone@domain.tld', which belongs to a locked account: xxxxx

By looking at the accounts with 'someone@domain.tld' I find one deleted account following the old delete account predent case which of course is locked.
The second account is an active not blocked account.

The problem seems to be a wrong sql statement where there is no check if the email is deleted.
Tags: vserver
Steps To Reproduce: OpenSSL Security Advisory [07 Apr 2014]
========================================

TLS heartbeat read overrun (CVE-2014-0160)
==========================================

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.
Additional Information: <?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
<title>git.cacert.org Git - cacert-devel.git/rss - pages/account/19.php history</title>
<link>https://git.cacert.org/gitweb/?p=cacert-devel.git;a=history;f=pages/account/19.php</link>
<description>CAcert's authoritative development repository</description>
<language>en</language>
<managingEditor>Software Assessors</managingEditor>
<image>
<url>static/git-logo.png</url>
<title>git.cacert.org Git - cacert-devel.git/rss - pages/account/19.php history</title>
<link>https://git.cacert.org/gitweb/?p=cacert-devel.git;a=history;f=pages/account/19.php</link>
</image>
<pubDate>Mon, 29 Mar 2010 07:54:06 +0000</pubDate>
<lastBuildDate>Mon, 29 Mar 2010 07:54:06 +0000</lastBuildDate>
<generator>gitweb v.1.7.10.4/1.7.10.4</generator>
<item>
<title>remove cacert/ prefix</title>
<author>Markus Warg <mw@it-sls.de></author>
<pubDate>Mon, 29 Mar 2010 07:54:06 +0000</pubDate>
<guid isPermaLink="true">https://git.cacert.org/gitweb/?p=cacert-devel.git;a=commitdiff;h=9dceece06fbdc98add6f76f0b1aec05891a394c4</guid>
<link>https://git.cacert.org/gitweb/?p=cacert-devel.git;a=commitdiff;h=9dceece06fbdc98add6f76f0b1aec05891a394c4</link>
<description>remove cacert/ prefix</description>
<content:encoded><![CDATA[
remove cacert/ prefix
]]>
</content:encoded>
</item>
</channel>
</rss>
System Description Default profile.
Attached Files:
Notes
(0005044)
INOPIAE   
2014-10-04 09:49   
fix available underhttps://github.com/INOPIAE/CAcert/commit/3a5f13b14f21ce3e0ff8107c31c563a9de8c3fb0


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1054 [Main CAcert Website] source code minor have not tried 2012-05-31 04:01 2021-08-25 13:37
Reporter: INOPIAE Platform:  
Assigned To: Ted OS:  
Priority: normal OS Version:  
Status: needs review & testing Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Review the code regarding the new point calculation in ./includes/general.php
Description: Check if the point calculation is adjusted according to the new points calculation.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0003161)
NEOatNHNG   
2012-08-27 13:35   
Dirk has done some changes which are available on the test server. Are they complete?
(0003163)
Uli60   
2012-08-28 10:40   
potential test scenarios affected by source code changes:

pages/wot/15.php
my details - my points - new calculation

pages/wot/6.php
assure someone, methods F2F and TTP

includes/general.php
  www.cacert.org and secure.cacert.org switch
  language detection
  switch "locked accounts"
  loadem section account.php?x index.php?y
  secure pwd validation (points regarding strong passwords)
       check on name parts, email address, dictionary
  cert subjectAltname routine, Common Name check on CSR's
      subjAltnames check, OU check on Org certs
  maxpoints routine, returns points you can issue
      check on points + assurer challenge levels
      and age of assurer (eg lt 18?)
  ping tests adding to pinglog table

|| why is philipp@c.o as rcpt added in line 642 ?!?
|| -> use function-alias eg support or sysadmin


  get-assurer-status
     checks: cats test passed, maxpoints, assurer-blocked

  no-assurer text switch

  is_assurer() using get-assurer-status

  generate-cert-path: client certs, server certs, org client certs, org server certs switch


includes/notary.inc.php
  get_number_of_assurances()
  get_number_of_assurees()
  get_top_assurer_position()
  get_top_assuree_position()
  get_given_assurances()
  get_received_assurances()
  get_given_assurances_summary()
  get_received_assurances_summary()
  get_cats_state()
  calc_experience()
  calc_assurances()
  show_user_link() name="" -> "System" or "Deleted account"
  get_assurer_ranking()
  get_assuree_ranking()
  output_ranking()
     general: output member mypoints (new calculation) and admin console new calculation
  check_date_limit(age) eg. PoJAM case calculation
  calc_points()
  max_points()
  output_summary_content() tested age limits 18, 14
  AssureMethodLine() eg assure someone with addtl. flags eg TTP, and potential others
(0003166)
INOPIAE   
2012-08-28 20:46   
(Last edited: 2012-08-28 21:21)
u14.1054@acme.com DOB 1.1.2000
assured with 35 points
=> no assurer => ok
added 70 points via batch => no assurer => OK
added CATS => shows assuer with 10 points => false
added 1 assurance added => assurance possible => false

u18.1054@acme.com DOB 1.1.1996
assured with 35 points => no assurer => ok
added 70 points via batch => no assurer => OK
added CATS
added 1 assurance =>ok
added 5 assurances via batch
All assurance show 10 points => ok
account has now 6 assurances
wot.id 15 show you can grant up to 15 points => should show 10 points
added new assurance with 20 points
Points reduced to 10 points according to PoJAM

my admin account
Added TTP assurance to oa.reinhard@acme.com with 35 points. => ok

(0003171)
Uli60   
2012-08-28 22:03   
test 1054.2.1
3 users
1054.2.1.user1@w.d
1054.2.1.admin1@w.d
1054.2.1.ttpadmin1@w.d

login 1054.2.1.admin1@w.d
set ttpadmin flag on 1054.2.1.ttpadmin1@w.d
=> ok

login 1054.2.1.ttpadmin1@w.d
assure someone
1054.2.1.user1@w.d

3 checkboxes

    F2F TTP
 A + - I certify that bug1004 userb4 has appeared in person

             "Only tick the next box if the Assurance was face to face."
             for TTP assurance this sentence is wrong

 B + + I believe that the assertion of identity I am making is correct,
             complete and verifiable. I have seen original documentation attesting
             to this identity. I accept that the CAcert Arbitrator may call upon me
             to provide evidence in any dispute, and I may be held responsible.

             original documentation?
              F2F - cap form
              TTP - ttpcap documentation


 C + + I have read and understood the Assurance Policy and the Assurance Handbook
             and am making this Assurance subject to and in compliance with the policy
             and handbook.

=> ok, except the "Only tick the next box if the Assurance was face to face."


new points:
for TTP assurance no experience points counted => ok
for F2F assurance 2 experience points counted => ok

f2f assurance
A not set => passes
  relates to points removal, reapply
  thawte patch 1023 or so
B set => ok
C set => ok
(0003172)
Uli60   
2012-08-28 22:52   
assure someone
user f2f only
method line no longer appears => ok

update 56ca0c87

assure someone
user ttpadmin, make ttp
method line, ttp selected
checkboxes A, B not set, C set =>
ERROR: You failed to check all boxes to validate your adherence to
the rules and policies of CAcert

I have explicitly set checkbox B in TTP assurance too
but this conflicts with line of info text:
"Only tick the next box if the Assurance was face to face."
(0003173)
Uli60   
2012-08-28 23:03   
release: 307f995b

assure someone
user f2f only
method line no longer appears => ok
"Only tick the next box if the Assurance was face to face." line no longer appears => ok

assure someone
user ttpadmin, make ttp
method line, ttp selected
"Only tick the next box if the Assurance was face to face." line no longer appears => ok
checkboxes A not set, B + C set => ok
(0003174)
NEOatNHNG   
2012-08-28 23:14   
I have ported changes that were present in the now deleted wot.inc.php and also did some minor improvements.
(0003175)
Uli60   
2012-09-04 21:54   
created new user 1054.2.1.user2@w.d
login 1054.2.1.ttpadmin1@w.d
assure someone: 1054.2.1.user2@w.d

F2F assurance
no checkboxes set
ERROR: You failed to check all boxes to validate your
    adherence to the rules and policies of CAcert
=> ok

all 3 set
passed
=> ok

new points calc display
261751 2012-09-04 Bug1054.2.1 User2 35 F2F of ttpadmin with selection F2F
     Face to Face Meeting 2
=> ok


created new user 1054.2.1.user3@w.d
login 1054.2.1.ttpadmin1@w.d
assure someone: 1054.2.1.user3@w.d

TTP-assisted-assurance
no checkboxes set
ERROR: You failed to check all boxes to validate your adherence to the
       rules and policies of CAcert
=> ok

checkboxes set:
I certify that Bug1054.2.1 User3 has appeared in person => No
I believe that the assertion of identity I am making is
   correct, complete and verifiable. I have seen original
   documentation attesting to this identity. => yes
I have read and understood AP => yes

passed
=> ok

new points calc display
261752 2012-09-04 Bug1054.2.1 User3 35
    TTP assurance, req ID [], req from 2012-08-28, TTP 2012-08-28
    Trusted Third Parties <> (empty points field)
=> ok


Summary:
new points:
for TTP assurance no experience points counted => ok
for F2F assurance 2 experience points counted => ok

checkboxes
              F2F TTP
i certify + -
i believe + +
i have read + +

all ok
(0003176)
Uli60   
2012-09-04 22:00   
(Last edited: 2012-09-04 22:02)
1054.1.1 new points calculation display (15.php)
summary of tables points given, points received
moved 2 columns to the right
=> fail

(10.php is ok)

(0003177)
Uli60   
2012-09-04 22:04   
1054.3.7
maxpoints routine, returns points you can issue
new points calc display (15.php)
max 35 => ok
assure someone: max 35 => ok
(0003178)
Uli60   
2012-09-04 22:10   
1054.4.1
get_number_of_assurances()
Assurer Ranking
You have made 30 assurances which ranks you as the 0000030 top assurer.

manual counted 35 assurances total
30 assurances F2F
5 assurances TTP
=> ok

proposal:
You have made 30 assurances which ranks you as the 0000030 top assurer. *)
*) note: F2F assurances only
(0003179)
Uli60   
2012-09-04 22:13   
1054.4.3
get_top_assurer_position()

1054.4.4
get_top_assuree_position()

Assurer Ranking
You have made 30 assurances which ranks you as the 0000030 top assurer.
You have received 3 assurances which ranks you as the 0000204 top assuree.
0000030 assurer => ok
0000204 assuree => ok
(0003180)
Uli60   
2012-09-04 22:26   
1054.1.1 column prob reviewed
own points 15.php
Total Assurance Points: (3 columns)
=> ok

login as admin, search user:
assurances user got - new calc (43.php)
Total Assurance Points: (5 columns)
=> ok

assurances user gave - new calc (43.php)
Total Points Issued: (5 columns)
=> ok
(0003182)
Uli60   
2012-09-04 23:07   
(Last edited: 2012-09-11 21:02)
scenario: 1054.3.3

new user 1054.3.3.user1@w.d
100 assurance points
assurer challenge passed
5 batch assurances
set flags: lock account
try to login 1054.3.3.user1@w.d
wrong email or wrong password
=> error message is misleading, but ok


login admin
search user 1054.3.3.user1@w.d
state: account locked

Account State
Account inconsistency: Users record locked set
code: 4
Account inconsistency can cause problems in daily account operations
 and needs to be fixed manually through arbitration/critical team.


login assurer
assure someone 1054.3.3.user1@w.d
assurance is possible, passed
261767 2012-09-05 Bug1054.3.3 User1 35
  test to locked account user Face to Face Meeting 2
=> mmh, but ok
   filed as separate bug
   assurance over potential weak user account ?!?

read https://bugs.cacert.org/view.php?id=1096

(0003185)
Uli60   
2012-09-11 21:10   
1054.3.1 (a) cacert / (b) secure switch test
  (a) http://cacert1.it-sls.de/index.php?id=13 (Donations footer link)
      http://cacert1.it-sls.de/index.php?id=51 (mission statement footer link)
      http://cacert1.it-sls.de/index.php?id=11 (contact us footer link)

login to useraccount ... results in
https://cacert1.it-sls.de link

using cert login
cert login to another user account results in:
https://secure1.it-sls.de link

  (b) https://secure1.it-sls.de/account.php?id=38 (donations secure footer link)
      mission statement under secure link still don't exist
      https://secure1.it-sls.de/account.php?id=40 (contact us secure footer link)



(a) cacert / (b) secure switch test
  works
=> Ok
(0003186)
Uli60   
2012-09-11 21:28   
1054.3.5
secure pwd validation (points regarding strong passwords)
check on name parts, email address, dictionary

testing pwd changes with 1054.2.1.user3@w.d

shortest known Pwd:
Failure: Pass Phrase not Changed
The Pass Phrase you submitted was too short.
=> ok

using email alias
Failure: Pass Phrase not Changed
The Pass Phrase you submitted failed to contain enough
differing characters and/or contained words from your name
and/or email address. Only scored 1 points out of 6.
=> ok

using name
Failure: Pass Phrase not Changed
The Pass Phrase you submitted failed to contain enough
differing characters and/or contained words from your name
and/or email address. Only scored 2 points out of 6.
=> ok

using 2 english known words (from dictionary)
Failure: Pass Phrase not Changed
The Pass Phrase you submitted failed to contain enough
differing characters and/or contained words from your name
and/or email address. Only scored 2 points out of 6.
=> ok

old Fred pwd
Failure: Pass Phrase not Changed
The Pass Phrase you submitted failed to contain enough
differing characters and/or contained words from your name
and/or email address. Only scored 0 points out of 6.
=> ok

using strong pwd
Pass Phrase Changed Successfully
Your Pass Phrase has been updated and your primary email
account has been notified of the change.
=> ok
(0003188)
INOPIAE   
2012-09-11 21:55   
Test 1054.3.2
On Test Ssytem
open homepage
change translation language to Spanish
Login into account with account language English => shows English
If use go home switch back to Spanish
Login again English
Logout => stays English

On Productive Ssytem
open homepage
change translation language to Spanish
Login into account with account language English => shows English
If use go home switch back to Spanish
Login again English
Logout => stays English

Both systems show same behavior
(0003189)
Uli60   
2012-09-11 23:37   
1054.3.8 age limits

(a) < 14 Bug1054.3.8.UserLT14 1.1.2000, 100 AP, passed CATS
(b) 14 < 18 Bug1054.3.8.UserIs15 1.1.1997, 100 AP,
(c) > 18 Bug1054.3.8.UserGT18 1.1.1990, 100 AP


test I receive assurances
test II give assurances
test III pass cats test

testmatrix

                   a b c
rcvd assurance pass x1), x2) pass x1) x4) pass x6)
give assurances requires III requires III requires III
pass cats unknown x3) unknown x5) unknown x7)


x1) in theory, this is a PoJAM assurance that needs
    an extra line: parental consent established
    but is not yet implemented in production
x2) new calculation 15.php
Summary of your Points
Description Points Countable Points Remark
Assurance Points you received 135 100 Limit reached
Total Experience Points by Assurance 0 0
Total Experience Points (other ways) 0 0
Total Points 100 You have to pass the CAcert Assurer
                                Challenge (CATS-Test) to be an Assurer

x3)
logged-in (<14 years old)
https://cacert1.it-sls.de/wot.php?id=2 "Becoming an Assurer"
link exist
includes link to https://cats.cacert.org/

cats test on testserver link is:
https://cats1.it-sls.de
first create client cert for user
 with Enable certificate login with this certificate
passed CATS test, needs transfer to cacert1
 => ted, michael
    with request to response for re-check the result

cats passed

logout from cats server (testserver ca-mgr1)
results in link: https://cats1.it-sls.de//index.php?
                                        ^^


x4)
Summary of your Points
Description Points Countable Points Remark
Assurance Points you received 135 100 Limit reached
Total Experience Points by Assurance 0 0
Total Experience Points (other ways) 0 0
Total Points 100 You have to pass the CAcert Assurer Challenge (CATS-Test)
                                to be an Assurer

x5)
logged-in (15 years old)
https://cacert1.it-sls.de/wot.php?id=2 "Becoming an Assurer"
link exist
includes link to https://cats.cacert.org/
cats test on testserver link is:
https://cats1.it-sls.de
first create client cert for user
 with Enable certificate login with this certificate

cats passed

logout from cats server (testserver ca-mgr1)
results in link: https://cats1.it-sls.de//index.php?
                                        ^^


x6)
Summary of your Points
Description Points Countable Points Remark
Assurance Points you received 135 100 Limit reached
Total Experience Points by Assurance 0 0
Total Experience Points (other ways) 0 0
Total Points 100 You have to pass the CAcert Assurer Challenge (CATS-Test)
                                to be an Assurer

x7)
logged-in (GT 18 years old)
https://cacert1.it-sls.de/wot.php?id=2 "Becoming an Assurer"
link exist
includes link to https://cats.cacert.org/
cats test on testserver link is:
https://cats1.it-sls.de
first create client cert for user
 with Enable certificate login with this certificate

cats passed

logout from cats server (testserver ca-mgr1)
results in link: https://cats1.it-sls.de//index.php?
                                        ^^

cannot continue with this test series until
the CATS tests made on the CATS test testserver are
transfered to cacert1.it-sls.de
(0003191)
Uli60   
2012-09-12 00:51   
1054.4.12
show_user_link() name="" -> "System" or "Deleted account"

create 2 user accounts, with 100 AP and passed CATS each


where to find "System" ?

doing assurances ... experience points issued
under My Points 10.php:

Your Assurance Points
ID Date Who Points Location Method
261780 2012-09-12 02:08:58 John 0 Doe 35 CAcert Test Manager Face to Face Meeting
261781 2012-09-12 02:08:58 John 1 Doe 35 CAcert Test Manager Face to Face Meeting
261782 2012-09-12 02:08:58 John 2 Doe 30 CAcert Test Manager Face to Face Meeting
261787 2012-09-12 Bug1054.4.12 User1 2 @home, CCA+ Administrative Increase
261789 2012-09-12 Bug1054.4.12 User1 2 @home, PoJAM+, CCA+ Administrative Increase
Total Points: 104

Assurance Points You Issued
ID Date Who Points Location Method
261786 2012-09-12 Bug1054.4.12 User2 0 @home, CCA+ Face to Face Meeting
261788 2012-09-12 Bug1054.3.8 UserIs15 0 @home, PoJAM+, CCA+ Face to Face Meeting
Total Points Issued: 0

under My Points 15.php:

Summary of your Points
Description Points Countable Points Remark
Assurance Points you received 100 100
Total Experience Points by Assurance 4 4
Total Experience Points (other ways) 0 0
Total Points 104 You may issue up to 10 points

Assurance Points You Issued
ID Date Who Points Location Method Experience Points
261786 2012-09-12 Bug1054.4.12 User2 10 @home, CCA+ Face to Face Meeting 2
261788 2012-09-12 Bug1054.3.8 UserIs15 10 @home, PoJAM+, CCA+ Face to Face Meeting 2
Total Points Issued: 20 Total Experience Points: 4

Your Assurance Points
ID Date Who Points Location Method Experience Points
261780 2012-09-12 02:08:58 John 0 Doe 35 CAcert Test Manager Face to Face Meeting 0
261781 2012-09-12 02:08:58 John 1 Doe 35 CAcert Test Manager Face to Face Meeting 0
261782 2012-09-12 02:08:58 John 2 Doe 30 CAcert Test Manager Face to Face Meeting 0
Total Assurance Points: 100 Total Experience Points: 0


"System" doesn't show up

10.php lists "Bug1054.4.12 User1" (own name) under listed administrative increase
experience points



User2:
login Admin (SE permissions)
search Bug1054.4.12.User2@w.d

walk through:
https://wiki.cacert.org/Arbitrations/Training/Lesson20/DeleteAccountProcSEv3
procedure
(not yet deleted)
under other users account, assurance is listed as:
a1054.4.12.1 a1054.4.12.1
under 15.php same, except the experience points are not
listed as individual administrative increases but as
assurance record, counted with 2 experience pts each assurance

relogin Admin account
search user a1054.4.12.1@w.d
delete account()
results in message:
"I'm sorry, the user you were looking for seems to have disappeared! Bad things are a foot!"

relogin to user account that assured deleted user
new calculation 15.php shows:
assurance over: a1054.4.12.1 a1054.4.12.1

"Deleted Account" doesn't show up

"Deleted Account" probably is displayed once the user created the account,
but still hasn't confirmed it and an assurer has passed an assurance
over this still unverified user account.
After 24/48 hours, the cleanup routine kills this user account
and probably the assurer reads "Deleted Account"


create new test user account 0000003
login to assurer #1
assure someone -> Bug1054.4.12.user3@w.d
results in: ERROR: User is not yet verified. Please try again in 24 hours!

Test scenario cannot pass
(0003194)
Uli60   
2012-09-12 16:24   
1054.3.8 age limits (cont.)

(a) < 14 Bug1054.3.8.UserLT14 1.1.2000, 100 AP, passed CATS
(b) 14 < 18 Bug1054.3.8.UserIs15 1.1.1997, 100 AP, passed CATS
(c) > 18 Bug1054.3.8.UserGT18 1.1.1990, 100 AP, passed CATS


test I receive assurances
test II give assurances
test III pass cats test

testmatrix

................... a ............. b ............. c .........
rcvd assurance ... pass .......... pass .......... pass
give assurances .. avail, fail x1) pass ok, x2) .. pass ok, x3)
pass cats ........ pass .......... pass .......... pass


verification step III

(a) Bug1054.3.8.UserLT14
Summary of your Points
Description Points Countable Points Remark
Assurance Points you received 135 100 Limit reached
Total Experience Points by Assurance 0 0
Total Experience Points (other ways) 0 0
Total Points 100 You may issue up to 10 points
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=> not ok

assure someone link is available
=> not ok

x1)
u14 isn't allowed to do assurances
as this is the current state of the software,
this isn't a bug here
to follow PoJAM policy a separate bug is filed
https://bugs.cacert.org/view.php?id=872

expected:
new calculation 15.php
you've passed CATS test, however you disqualify
as an assurer by PoJAM restrictions




(b) Bug1054.3.8.UserIs15
Summary of your Points
Description Points Countable Points Remark
Assurance Points you received 145 100 Limit reached
Total Experience Points by Assurance 0 0
Total Experience Points (other ways) 0 0
Total Points 100 You may issue up to 10 points
=> ok

assure someone link is available
=> ok

x2)
between age of 14 and 18, an assurer can issue upto
max 10 assurance points
no matter of experiences

doing 5 assurances 10 AP each
=> ok

doing more then 5 assurances
max 10 AP each (limited)
=> ok

Assurance Points You Issued
ID Date Who Points Location Method Experience Points
261791 2012-09-12 bug1004 userb4 10 PoJAM assurer, CCA+ Face to Face Meeting 2
261793 2012-09-12 Bug1070 User 10 PoJAM assurer, CCA+ Face to Face Meeting 2
261795 2012-09-12 bug1004 userb5 10 PoJAM assurer, CCA+ Face to Face Meeting 2
261797 2012-09-12 Bug1004 User2 10 PoJAM assurer, CCA+ Face to Face Meeting 2
261799 2012-09-12 bug1004 userb3 10 PoJAM assurer, CCA+ Face to Face Meeting 2
261801 2012-09-12 Bug 846 User2 10 PoJAM assurer, CCA+ Face to Face Meeting 2
261803 2012-09-12 Bug922 User2 10 PoJAM assurer, CCA+ Face to Face Meeting 2
Total Points Issued: 70 Total Experience Points: 14
=> ok



(c) Bug1054.3.8.UserGT18
Summary of your Points
Description Points Countable Points Remark
Assurance Points you received 135 100 Limit reached
Total Experience Points by Assurance 0 0
Total Experience Points (other ways) 0 0
Total Points 100 You may issue up to 10 points
=> ok

assure someone link is available
=> ok

x3)
over 18, assurer follows regular experience levels
first 5 assurances -> max 10 AP
2nd set of 5 assurances -> max 15 AP
and so forth

doing 5 assurances 10 AP each
=> ok

doing assurances 6-10, 15 AP each
=> ok

doing assurances 11-15, 20 AP each
=> ok

doing assurances 16-20, 25 AP each
=> ok

doing assurances 21-25, 30 AP each
=> ok

doing assurances 25 and more, max 35 AP each
=> ok
(0003200)
Uli60   
2012-09-18 21:24   
1054.3.9 write PingLog entries
in SA project team meeting, NEO checked PingLog table
last entries from last weeks Tuesdays meeting
of bug1054 test users
=> ok
(0003201)
Uli60   
2012-09-19 00:21   
1054.4.19 "how many points an assurer can award at max"
checked in several tests
1054.4.20 output_summary_content() tested age limits 18, 14 (see also 1054.3.8)
tested under 1054.3.8
1054.3.4 loadem routine, several tests doesn't disclose a problem in
switching between different pages (different id=x pages)
1054.4.19 max_points() how many points an assurer can award at max
tested under 1054.4.19
1054.4.9 get_cats_state() newpoints 15.php several times checked, ok
1054.4.10 calc_experience() calculate EP points summarize, no anomaly detected in tests, ok
1054.4.11 calc_assurances() calculate AP points summarize, no anomaly detected in tests, ok
1054.4.13 get_assurer_ranking() stats for 15.php, no anomaly detected in tests, ok
1054.4.14 get_assuree_ranking() stats for 15.php no anomaly detected in tests, ok
1054.4.15 output_ranking(), tested under 1054.4.13 + 1054.4.14
1054.3.10 get-assurer-status<
> checks: cats test passed, maxpoints, assurer-blocked. cats passed tested, maxpoints tested, assurer-blocked not yet tested
1054.3.11 no-assurer text switch, checked, ok
1054.3.12 is_assurer() using get-assurer-status, checked, ok
1054.3.13 generate-cert-path: client certs, server certs, org client certs, org server certs switch, several certs created, signed certs received, so procedure works as expected, low level check impossible for software testers. ok
(0003202)
Uli60   
2012-09-19 00:50   
(Last edited: 2012-09-19 00:57)
scenario 1054.3.10

new user 1054.3.10.user1@w.d
setting 100 AP, assurer challenge, 50 EP

login 1054.3.10.user1@w.d
assure someone: 1054.2.1.user1@w.d
max points (0)
enter points: 35
15.php: 0 pts awarded

-NEO did some changes-

again:
assure someone: Bug1054.2.1 User3
max points (35)
enter points: 35
15.php: 35 pts awarded


setting block assurer flag

login user: 1054.3.10.user1@w.d
assure someone
"ERROR: Sorry, you are not allowed to be an Assurer.
 Please contact cacert-support@lists.cacert.org
 if you feel that this is not corect."
                                ^^ correct with two "r"
=> ok

unblock assurer

test again
assure someone: Bug1054.3.8 UserGT18
max points: (35)
enter points: 35
15.php: 35 pts awarded
=> ok

setting block assurer flag

Assure someone: -> error message (see above)
15.php summary:
Summary of your Points
Description Points Countable Points Remark
Assurance Points you received 100 100
Total Experience Points by Assurance 56 50 Limit reached
Total Experience Points (other ways) 0 0
Total Points 150 You may issue up to 35 points
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
wrong message: shall be "assurer status blocked"
or similar message
=> not ok in 15.php

(0003204)
Uli60   
2012-09-20 21:54   
1054.3.6 part I

test #1 - client certs variations
using bug 0000440 test account, 150pts assurer
similar to test
https://bugs.cacert.org/view.php?id=440#c2833
re-test

create client cert
a) email 1
   class1
   no name
   enable cert login

   create client cert
   install client cert x1)

Valid certs.test@w.d 115C Not Revoked 2012-10-20 21:04:00

   serno: 115c
   displ.name: CAcert WoT User -> ok
   valid from/to: 20.09.2012 23:04:00 / 20.10.2012 23:04:00 -> ok
   owner: E = certs.test@w.d, CN = CAcert WoT User -> ok

   extended key usage:
    Nicht kritisch
    E-Mail-Schutz (1.3.6.1.5.5.7.3.4)
    TLS-Web-Client-Authentifikation (1.3.6.1.5.5.7.3.2)
    Microsoft-Dateisystemverschlüsselung (1.3.6.1.4.1.311.10.3.4)
    Microsoft servergesperrte Kryptographie (1.3.6.1.4.1.311.10.3.3)
    Netscape servergesperrte Kryptographie (2.16.840.1.113730.4.1)

    certs alternate name
    Nicht kritisch
    E-Mail-Adresse: certs.test@w.d

    => all ok

b) email 1
   class3
   no name
   enable cert login

   create client cert
   install client cert x1)

Valid certs.test@w.d 10D6 Not Revoked 2012-10-20 21:14:31


   serno: 10D6
   displ.name: CAcert WoT User -> ok
   valid from/to: 20.09.2012 23:14:31 / 20.10.2012 23:14:31 -> ok
   owner: E = certs.test@w.d, CN = CAcert WoT User -> ok

   extended key usage:
    Nicht kritisch
    E-Mail-Schutz (1.3.6.1.5.5.7.3.4)
    TLS-Web-Client-Authentifikation (1.3.6.1.5.5.7.3.2)
    Microsoft-Dateisystemverschlüsselung (1.3.6.1.4.1.311.10.3.4)
    Microsoft servergesperrte Kryptographie (1.3.6.1.4.1.311.10.3.3)
    Netscape servergesperrte Kryptographie (2.16.840.1.113730.4.1)

   certs alternate name
    Nicht kritisch
    E-Mail-Adresse: certs.test@w.d

   => all ok

c) email 1
   class1
   "Certs Test"
   enable cert login

   create client cert
   install client cert x1)

Valid certs.test@w.d 115D Not Revoked 2012-10-20 21:26:44

   serno: 115d
   displ.name: Certs Test -> ok
   owner: E = certs.test@w.d, CN = Certs Test -> ok

   extended key usage -> ok
   cert alternate name:
    Nicht kritisch
    E-Mail-Adresse: certs.test@w.d ->

  => all ok

d) email 1
   class3
   "Certs Test"
   enable cert login

   create client cert
   install client cert x1)

Valid certs.test@w.d 10D7 Not Revoked 2012-10-20 21:32:52

   serno: 10d7
   displ.name: Certs Test -> ok
   owner: E = certs.test@w.d, CN = Certs Test -> ok

   extended key usage -> ok
   cert alternate name:
    Nicht kritisch
    E-Mail-Adresse: certs.test@w.d -> ok

  => all ok

e) email 1
   class1
   "Certs Sub Test"
   enable cert login

   create client cert
   install client cert x1)

Valid certs.test@w.d 115E Not Revoked 2012-10-20 21:37:02

   serno: 115e
   displ.name: Certs Sub Test -> ok
   owner: E = certs.test@w.d, CN = Certs Sub Test -> ok

   extended key usage -> ok
   cert alternate name:
    Nicht kritisch
    E-Mail-Adresse: certs.test@w.d -> ok

  => all ok

f) email 1
   class3
   "Certs Sub Test"
   enable cert login

   create client cert
   install client cert x1)

Valid certs.test@w.d 10D8 Not Revoked 2012-10-20 21:46:32

   serno: 10d8
   displ.name: Certs Sub Test -> ok

   owner: E = certs.test@w.d, CN = Certs Sub Test -> ok
   extended key usage:
    Nicht kritisch
    E-Mail-Schutz (1.3.6.1.5.5.7.3.4)
    TLS-Web-Client-Authentifikation (1.3.6.1.5.5.7.3.2)
    Microsoft-Dateisystemverschlüsselung (1.3.6.1.4.1.311.10.3.4)
    Microsoft servergesperrte Kryptographie (1.3.6.1.4.1.311.10.3.3)
    Netscape servergesperrte Kryptographie (2.16.840.1.113730.4.1)

   certs alternate name
   Nicht kritisch
   E-Mail-Adresse: certs.test@w.d

   => all ok

x1)
runs into fix https://bugs.cacert.org/view.php?id=1017
/account.php?id=6 list 3 options
a. Install the certificate into your browser
b. Download the certificate in PEM format
c. Download the certificate in DER format
using a. with FF

see also https://bugs.cacert.org/view.php?id=440#c3203
(0003207)
Uli60   
2012-09-21 12:52   
1054.3.6 part II

test 0000002 - server certs variations
similar to test
https://bugs.cacert.org/view.php?id=440#c2839
re-test

using prev account from bug#440 testing
using prev used domain under bug#440 testing

openssl genrsa -out test1-avintec-com-512.key 512
openssl req -new -key test1-avintec-com-512.key -out test1-avintec-com-512.csr

paste csr

sign class1
<paste>
submit

error/warning
"The keys that you use are very small and therefore insecure.
Please generate stronger keys. More information about this
issue can be found in the wiki"

=> ok

openssl genrsa -out test1-avintec-com-1024.key 1024
openssl req -new -key test1-avintec-com-1024.key -out test1-avintec-com-1024.csr

sign class1
<paste>
submit

Please make sure the following details are correct before proceeding any further.

CommonName: test1.avintec.com
No additional information will be included on certificates because it can not be automatically checked by the system.

submit

returns:
Below is your Server Certificate

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

new file test1-avintec-com-1024-signed-c1.key
<paste>

key in list:
 Valid test1.avintec.com 115F Not Revoked 2012-10-21 12:19:20

openssl x509 -text -in test1-avintec-com-1024-signed-c1.key -noout
....................................................................
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4447 (0x115f)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AU, ST=New South Wales, O=CAcert Testserver, OU=http://cacert1
.it-sls.de, CN=CAcert Testserver Root
        Validity
            Not Before: Sep 21 12:19:20 2012 GMT
            Not After : Oct 21 12:19:20 2012 GMT
        Subject: CN=test1.avintec.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
[...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication, Ne
tscape Server Gated Crypto, Microsoft Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org/

            X509v3 CRL Distribution Points:
                URI:http://crl.cacert.org/revoke.crl

            X509v3 Subject Alternative Name:
                DNS:test1.avintec.com, othername:<unsupported>
    Signature Algorithm: sha1WithRSAEncryption
....................................................................
=> ok



openssl genrsa -out test1-avintec-com-2048.key 2048
openssl req -new -key test1-avintec-com-2048.key -out test1-avintec-com-2048.csr

sign class1
<paste>
submit

Please make sure the following details are correct before proceeding any further.

CommonName: test1.avintec.com
No additional information will be included on certificates because it can not be automatically checked by the system.

submit

returns:
Below is your Server Certificate

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

new file test1-avintec-com-2048-signed-c1.key
<paste>

key in list:
 Valid test1.avintec.com 1160 Not Revoked 2012-10-21 12:43:39

openssl x509 -text -in test1-avintec-com-2048-signed-c1.key -noout
......................................................
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4448 (0x1160)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AU, ST=New South Wales, O=CAcert Testserver, OU=http://cacert1
.it-sls.de, CN=CAcert Testserver Root
        Validity
            Not Before: Sep 21 12:43:39 2012 GMT
            Not After : Oct 21 12:43:39 2012 GMT
        Subject: CN=test1.avintec.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
[...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication, Ne
tscape Server Gated Crypto, Microsoft Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org/

            X509v3 CRL Distribution Points:
                URI:http://crl.cacert.org/revoke.crl

            X509v3 Subject Alternative Name:
                DNS:test1.avintec.com, othername:<unsupported>
    Signature Algorithm: sha1WithRSAEncryption
[...]
......................................................
=> ok

see also https://bugs.cacert.org/view.php?id=440#c3206
(0003208)
Uli60   
2012-09-21 13:12   
1054.3.6 part III

test 0000003 - client certs variations, multiple emails in cert
using prev account from bug#440 testing

adding 2 more email addresses to test account
old 1. certs.test@w.d
add 2. bug1054.3.6.3.user1@w.d
add 3. bug1054.3.6.3.user2@w.d

email accounts - view:
prim Verified N/A certs.test@w.d
sec1 Verified bug1054.3.6.3.user1@w.d
sec2 Verified bug1054.3.6.3.user2@w.d

=> ok

client cert - new

selecting email 1-3
class 1
Include 'Certs Sub Test'
enable cert login

Next

Create Cert Request (High)

Install the certificate into your browser

cert has been installed ....

client certs - view:
addtl. key:
Valid certs.test@w.d 1161 Not Revoked 2012-10-21 13:02:39

Name: Certs Sub Test -> ok
Valid from/to: 21.09.2012 15:02:39 / 21.10.2012 15:02:39 -> ok
owner:
E = bug1054.3.6.3.user2@w.d
E = bug1054.3.6.3.user1@w.d
E = certs.test@w.d
CN = Certs Sub Test
     -> ok

cert alternate name(s):
Nicht kritisch
E-Mail-Adresse: certs.test@w.d
E-Mail-Adresse: bug1054.3.6.3.user1@w.d
E-Mail-Adresse: bug1054.3.6.3.user2@w.d
      -> ok

openssl x509 -text -in client-cert-CertsSubTest-c1-3addr.pem -noout
..............................................................
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4449 (0x1161)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AU, ST=New South Wales, O=CAcert Testserver, OU=http://cacert1
.it-sls.de, CN=CAcert Testserver Root
        Validity
            Not Before: Sep 21 13:02:39 2012 GMT
            Not After : Oct 21 13:02:39 2012 GMT
        Subject: CN=Certs Sub Test/emailAddress=certs.test@w.d/emailAddre
ss=bug1054.3.6.3.user1@w.d/emailAddress=bug1054.3.6.3.user2@w.d
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
[...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            Netscape Comment:
                To get your own certificate for FREE head over to http://www.CAc
ert.org
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                E-mail Protection, TLS Web Client Authentication, Microsoft Encr
ypted File System, Microsoft Server Gated Crypto, Netscape Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org

            X509v3 CRL Distribution Points:
                URI:http://crl.cacert.org/revoke.crl

            X509v3 Subject Alternative Name:
                email:certs.test@w.d, email:bug1054.3.6.3.user1@w.d,
email:bug1054.3.6.3.user2@w.d
    Signature Algorithm: sha1WithRSAEncryption
[...]
..............................................................
=> seems to be ok
(0003211)
Uli60   
2012-09-21 14:47   
1054.3.6 part IV

test 0000004

server cert variation
multiple servernames in one csr

openssl genrsa -out test2-avintec-com-2048.key 2048
openssl req -new -key test2-avintec-com-2048.key -out test2-avintec-com-2048.csr

using:
Common Name (e.g. server FQDN or YOUR name) []:test1.avintec.com,mail.avintec.co
m,www.avintec.com,www.fra.avintec.com,mx.avintec.com,support.avintec.com

string is too long, it needs to be less than 64 bytes long
Common Name (e.g. server FQDN or YOUR name) []:test1.avintec.com

ok, again ...
how to enter multiple hostnames into an csr request ?

see http://apetec.com/support/GenerateSAN-CSR.htm

copy openssl.cnf to openssl-san.cfg
edit openssl-san.cfg
adding:
............................................................
[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = test1.avintec.com
DNS.2 = mail.avintec.com
DNS.3 = www.avintec.com
DNS.4 = www.fra.avintec.com
DNS.5 = mx.avintec.com
DNS.6 = support.avintec.com
............................................................

starting script:

openssl genrsa -out test2-avintec-com-2048.key 2048
openssl req -new -out test2-avintec-com-2048.csr -key test2-avintec-com-2048.key -config openssl-san.cfg

copy content of test2-avintec-com-2048.csr
as server signing request

 Please make sure the following details are correct before proceeding any further.

CommonName: test1.avintec.com
No additional information will be included on certificates because it can
 not be automatically checked by the system.

submit

Below is your Server Certificate

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

output to file test2-avintec-com-2048-signed-c1.key

openssl x509 -text -in test2-avintec-com-2048-signed-c1.key -noout
.................................................................
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4450 (0x1162)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AU, ST=New South Wales, O=CAcert Testserver, OU=http://cacert1
.it-sls.de, CN=CAcert Testserver Root
        Validity
            Not Before: Sep 21 13:50:27 2012 GMT
            Not After : Oct 21 13:50:27 2012 GMT
        Subject: CN=test1.avintec.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
[...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication, Ne
tscape Server Gated Crypto, Microsoft Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org/

            X509v3 CRL Distribution Points:
                URI:http://crl.cacert.org/revoke.crl

            X509v3 Subject Alternative Name:
                DNS:test1.avintec.com, othername:<unsupported>
    Signature Algorithm: sha1WithRSAEncryption
[...]
.................................................................
=> fail
   subjAltNames not transfered :-P

procedural problem ?!?

verifying csr request:
openssl req -text -noout -in test2-avintec-com-2048.csr

.................................................................
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=DE, ST=Germany, L=Frankfurt/Main, O=AVINTEC, OU=IT, CN=test1.
avintec.com/emailAddress=certs.test@w.d
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
[...]
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha1WithRSAEncryption
[...]
.................................................................

no SAN's :-P

correct conf file has been used as some parameters
has been changed to other default values, shown in
the interactive openssl keygen process

probably the conf parameter
[req]
req_extensions = v3_req
was missing, retrying ....

openssl genrsa -out test2-avintec-com-2048.key 2048
openssl req -new -out test2-avintec-com-2048.csr -key test2-avintec-com-2048.key -config openssl-san.cfg

testing csr:
openssl req -text -noout -in test2-avintec-com-2048.csr
.................................................................
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=DE, ST=Germany, L=Frankfurt/Main, O=AVINTEC, OU=IT, CN=test1.
avintec.com/emailAddress=certs.test@w.d
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
[...]
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Alternative Name:
                DNS:test1.avintec.com, DNS:mail.avintec.com, DNS:www.avintec.com
, DNS:www.fra.avintec.com, DNS:mx.avintec.com, DNS:support.avintec.com
    Signature Algorithm: sha1WithRSAEncryption
[...]
.................................................................
=> seems to be ok until this state

copy & paste content of test2-avintec-com-2048.csr
to the signing request

results in:
 Please make sure the following details are correct before proceeding any further.

CommonName: test1.avintec.com
subjectAltName: DNS:test1.avintec.com
subjectAltName: DNS:mail.avintec.com
subjectAltName: DNS:www.avintec.com
subjectAltName: DNS:www.fra.avintec.com
subjectAltName: DNS:mx.avintec.com
subjectAltName: DNS:support.avintec.com
No additional information will be included on certificates because it can not be automatically checked by the system.

submit

Below is your Server Certificate

-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----

copy & paste into new file
test2-avintec-com-2048-signed-c1.key

testing key
openssl x509 -text -in test2-avintec-com-2048-signed-c1.key -noout
.......................................................................
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4451 (0x1163)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AU, ST=New South Wales, O=CAcert Testserver, OU=http://cacert1
.it-sls.de, CN=CAcert Testserver Root
        Validity
            Not Before: Sep 21 14:41:43 2012 GMT
            Not After : Oct 21 14:41:43 2012 GMT
        Subject: CN=test1.avintec.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
[...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication, Ne
tscape Server Gated Crypto, Microsoft Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org/

            X509v3 CRL Distribution Points:
                URI:http://crl.cacert.org/revoke.crl

            X509v3 Subject Alternative Name:
                DNS:test1.avintec.com, othername:<unsupported>, DNS:mail.avintec
.com, othername:<unsupported>, DNS:www.avintec.com, othername:<unsupported>, DNS
:www.fra.avintec.com, othername:<unsupported>, DNS:mx.avintec.com, othername:<un
supported>, DNS:support.avintec.com, othername:<unsupported>
    Signature Algorithm: sha1WithRSAEncryption
.......................................................................
=> seems to be ok

see also https://bugs.cacert.org/view.php?id=440#c3210
(0003212)
Uli60   
2012-09-21 21:48   
1054.3.6 part V

client certs variation
renewal of cert

1. Valid certs.test@w.d 115C Not Revoked 2012-10-20 21:04:00

Now renewing the following certificates:
Certificate for 'certs.test@w.d' has been renewed.
Click here to install your certificate.

(next page) x1)
Install your certificate
Install the certificate into your browser

new cert
Valid certs.test@w.d 1164 Not Revoked 2012-10-21 21:26:44

(next cert after Serial Number: 4449 (0x1161) -> 1164)

cert serno 115c no longer in list

view all certs, 115c listed:
Valid certs.test@w.d 115C Not Revoked 2012-10-20 21:04:00


cert serno 1164 details:
not yet visible in FF cert store
ok, retrying to save new key in FF cert store

Install the certificate into your browser
https://cacert1.it-sls.de/account.php?id=6&cert=259099&install
result: cert stored in cert store ... (or similar msg)

now cert is visible in FF cert store

Serno: 11:64
valid from/to: 21.09.2012 23:26:44 / 21.10.2012 23:26:44
owner:
E = certs.test@w.d
CN = CAcert WoT User
-> ok

cert-alternate-name
Nicht kritisch
E-Mail-Adresse: certs.test@w.d
-> ok


2. renew key
-------------------------------------------------------------
Valid certs.test@w.d 1161 Not Revoked 2012-10-21 13:02:39

Name: Certs Sub Test -> ok
Valid from/to: 21.09.2012 15:02:39 / 21.10.2012 15:02:39 -> ok
owner:
E = bug1054.3.6.3.user2@w.d
E = bug1054.3.6.3.user1@w.d
E = certs.test@w.d
CN = Certs Sub Test
-------------------------------------------------------------

Now renewing the following certificates:
Certificate for 'certs.test@w.d' has been renewed.
Click here to install your certificate.
https://cacert1.it-sls.de/account.php?id=6&cert=259100

x1)

link opens new window/tab ...
-> problem

Install your certificate
Install the certificate into your browser
https://cacert1.it-sls.de/account.php?id=6&cert=259100&install

cert saved to cert store

new cert in list:
     Valid certs.test@w.d 1165 Not Revoked 2012-10-21 21:41:56

prev cert not in main list
view all certs (cert still there)
Valid certs.test@w.d 1161 Not Revoked 2012-10-21 13:02:39


cert 1165 details
serno: 11:65
valid from/to: 21.09.2012 23:41:56 / 21.10.2012 23:41:56 -> ok
owner:
E = bug1054.3.6.3.user2@w.d
E = bug1054.3.6.3.user1@w.d
E = certs.test@w.d
CN = Certs Sub Test
-> ok

externded keyusage -> ok

cert-alternate-name:
Nicht kritisch
E-Mail-Adresse: certs.test@w.d
E-Mail-Adresse: bug1054.3.6.3.user1@w.d
E-Mail-Adresse: bug1054.3.6.3.user2@w.d
-> ok

=> all ok except problem of https://bugs.cacert.org/view.php?id=1017
   routine



x1)
runs into fix https://bugs.cacert.org/view.php?id=1017 [^]
/account.php?id=6 list 3 options
a. Install the certificate into your browser
b. Download the certificate in PEM format
c. Download the certificate in DER format
using a. with FF
(0003215)
Uli60   
2012-09-21 22:23   
1054.3.6 part VI

server certs variation
renewal of cert

1. Valid test1.avintec.com 115F Not Revoked 2012-10-21 12:19:20

details original cert
openssl x509 -text -in test1-avintec-com-1024-signed-c1.key -noout
....................................................................
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4447 (0x115f)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AU, ST=New South Wales, O=CAcert Testserver, OU=http://cacert1 [^]
.it-sls.de, CN=CAcert Testserver Root
        Validity
            Not Before: Sep 21 12:19:20 2012 GMT
            Not After : Oct 21 12:19:20 2012 GMT
        Subject: CN=test1.avintec.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
[...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication, Ne
tscape Server Gated Crypto, Microsoft Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org/ [^]

            X509v3 CRL Distribution Points:
                URI:http://crl.cacert.org/revoke.crl [^]

            X509v3 Subject Alternative Name:
                DNS:test1.avintec.com, othername:<unsupported>
    Signature Algorithm: sha1WithRSAEncryption
....................................................................
=> ok


starting renewal:
Now renewing the following certificates:
Processing request 302035:
Renewing: test1.avintec.com

-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----

content saved to test1-renewal-115f-signed-c1.key

new key after renewal:
Valid test1.avintec.com 1166 Not Revoked 2012-10-21 22:06:42

old key 115f not visible in main server certs list
view all certs (shows in the list)
     Valid test1.avintec.com 115F Not Revoked 2012-10-21 12:19:20

details of server cert 0001166

openssl x509 -text -in test1-renewal-115f-signed-c1.key -noout
.................................................................
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4454 (0x1166)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AU, ST=New South Wales, O=CAcert Testserver, OU=http://cacert1
.it-sls.de, CN=CAcert Testserver Root
        Validity
            Not Before: Sep 21 22:06:42 2012 GMT
            Not After : Oct 21 22:06:42 2012 GMT
        Subject: CN=test1.avintec.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
[...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication, Ne
tscape Server Gated Crypto, Microsoft Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org/

            X509v3 CRL Distribution Points:
                URI:http://crl.cacert.org/revoke.crl

            X509v3 Subject Alternative Name:
                DNS:test1.avintec.com, othername:<unsupported>
    Signature Algorithm: sha1WithRSAEncryption
[...]
.................................................................
=> ok


2. Valid test1.avintec.com 1163 Not Revoked 2012-10-21 14:41:43
details original cert
openssl x509 -text -in test2-avintec-com-2048-signed-c1.key -noout
.......................................................................
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4451 (0x1163)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AU, ST=New South Wales, O=CAcert Testserver, OU=http://cacert1 [^]
.it-sls.de, CN=CAcert Testserver Root
        Validity
            Not Before: Sep 21 14:41:43 2012 GMT
            Not After : Oct 21 14:41:43 2012 GMT
        Subject: CN=test1.avintec.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
[...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication, Ne
tscape Server Gated Crypto, Microsoft Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org/ [^]

            X509v3 CRL Distribution Points:
                URI:http://crl.cacert.org/revoke.crl [^]

            X509v3 Subject Alternative Name:
                DNS:test1.avintec.com, othername:<unsupported>, DNS:mail.avintec
.com, othername:<unsupported>, DNS:www.avintec.com, othername:<unsupported>, DNS
:www.fra.avintec.com, othername:<unsupported>, DNS:mx.avintec.com, othername:<un
supported>, DNS:support.avintec.com, othername:<unsupported>
    Signature Algorithm: sha1WithRSAEncryption
.......................................................................
=> ok

starting renewal:
Now renewing the following certificates:
Processing request 302038:
Renewing: test1.avintec.com

-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----

content saved to test2-renewal-1163-signed-c1.key

new key after renewal:
     Valid test1.avintec.com 1167 Not Revoked 2012-10-21 22:17:20

old key 1163 not visible in main server certs list
view all certs (shows in the list)
     Valid test1.avintec.com 1163 Not Revoked 2012-10-21 14:41:43


details of server cert 0001166
openssl x509 -text -in test2-renewal-1163-signed-c1.key -noout
.................................................................
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4455 (0x1167)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AU, ST=New South Wales, O=CAcert Testserver, OU=http://cacert1
.it-sls.de, CN=CAcert Testserver Root
        Validity
            Not Before: Sep 21 22:17:20 2012 GMT
            Not After : Oct 21 22:17:20 2012 GMT
        Subject: CN=test1.avintec.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
[...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication, Ne
tscape Server Gated Crypto, Microsoft Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org/

            X509v3 CRL Distribution Points:
                URI:http://crl.cacert.org/revoke.crl

            X509v3 Subject Alternative Name:
                DNS:test1.avintec.com, othername:<unsupported>, DNS:mail.avintec
.com, othername:<unsupported>, DNS:www.avintec.com, othername:<unsupported>, DNS
:www.fra.avintec.com, othername:<unsupported>, DNS:mx.avintec.com, othername:<un
supported>, DNS:support.avintec.com, othername:<unsupported>
    Signature Algorithm: sha1WithRSAEncryption
[...]
.................................................................
=> ok


=> all ok
(0003218)
Uli60   
2012-09-21 23:48   
(Last edited: 2012-09-21 23:50)
1054.4.12
show_user_link() name="" -> "System" or "Deleted account"
under user account ulrich@c.o
admin console
Show Assurances the user gave (New calculation)
                               ^^^^^^^^^^^^^^^
assurance id: 255093
255093 11.08.2010 2010-08-11 01:00:44 Deleted account <=== 1 Testserver, -CCA Face to Face Meeting 2
=> ok

(0003219)
Uli60   
2012-09-21 23:53   
1054.4.16

login to an "old" account with several "buggy" notary table entries
eg empty assurance method lines, tverify points, TTP points,
"yellow" lines
check new points calculation 15.php

login to admin account search user in admin interface
show member user received / gave new calculation

compare both tables

10.php
old calculations
mixed methods:
Face to Face Meeting, Administrative Increase, CT Magazine - Germany,
"Project-Id-Version: CAcert Production Report-Msgid-Bugs-To: translations-admin@cacert.org POT-Creation-Date: 2012-09-17 10:51+0200 PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE Last-Translator: FULL NAME Language-Team: LANGUAGE Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Generator: Translate Toolkit 1.9.0 " (!!!)
Thawte Points Transfer
assurance points rcvd total: 200

assurances given:
methods:
Face to Face Meeting, <empty> (was several TTP assurance), Thawte Points Transfer
assurance points given total: 2342

15.php
Summary of your Points
Description Points Countable Points Remark
Assurance Points you received 719 100 Limit reached
Total Experience Points by Assurance 270 50 Limit reached
Total Experience Points (other ways) 173 0 Limit reached
        Total Points 150 You may issue up to 35 points

assurance pts given:
Face to Face Meeting, <empty> (was several TTP assurance), Thawte Points Transfer
assurance points given total: 6024, EPs 270

assurance pts rcvd:
methods: Face to Face Meeting, Thawte Points Transfer, <empty> (was TTP),
Administrative Increase, CT Magazine - Germany
total pts: 719, EP 173


admin console
Show Assurances the user got (New calculation)
                              ^^^^^^^^^^^^^^^
methods: Face to Face Meeting, Thawte Points Transfer, <empty> (was TTP),
Administrative Increase, CT Magazine - Germany
total pts: 719, EP 173


Show Assurances the user gave (New calculation)
                               ^^^^^^^^^^^^^^^
methods: Face to Face Meeting, <empty> (was TTP), Thawte Points Transfer,
total points issued: 6024, EP 270
(0003220)
Uli60   
2012-09-22 00:36   
(Last edited: 2012-09-22 00:38)
1054.4.18 + 1054.4.21
using outputs from 1054.4.16
print to pdf for better compare

inspect 0 records under 10.php
inspect different assurance methods and their results
compare to related records (use assurance id)
under 15.php

tables switched between 10.php and 15.php,
table points rcvd is top in 10.php
                  is bottom in 15.php
table points given is bottom in 10.php
                   is top in 15.php

eg

10: 183546 / 2010-08-04 13:34:54 / John 5 Doe / 0 / CAcert Test Manager / F2F
15: 183546 / 2010-08-04 13:34:54 / John 5 Doe / 30 / CAcert Test Manager / F2F / 0
-> ok

10: 183324 / 2010-07-05 / Andreas Baess / 5 / Im Testsystem vertraue ich jedem :-) / F2F
15: 183324 / 2010-07-05 / Andreas Baess / 5 / Im Testsystem vertraue ich jedem :-) / F2F / 0
-> ok

10: 183502 / 04.08.2010 / Ulrich Schroeter / 2 / Testsystem, +CCA / Administrative Increase
15: not found
-> ok

10: 255390 / 2010-09-01 22:40:22 / Mario Lipinski / 0 / CT / CT Magazine
15: 255390 / 2010-09-01 22:40:22 / Mario Lipinski / Revoked / CT / CT Magazine / 0
-> ok

10: 255389 / 2010-09-01 22:39:14 / Mario Lipinski / 0 / Admin Incr. / Admin Incr.
15: 255389 / 2010-09-01 22:39:14 / Mario Lipinski / 9 / Admin Incr. / Admin Incr. / 0
-> ok

10: 255388 / 2010-09-01 22:37:23 / Mario Lipinski / 0 / TTP / x1)
15: 255388 / 2010-09-01 22:37:23 / Mario Lipinski / 100 / TTP / <empty> / 23
-> ok

10: 255383 / 2010-08-25 10:37:47 / Mario Lipinski / 50 / 38102 / Thawte Points Transfer
15: 255383 / 2010-08-25 10:37:47 / Mario Lipinski / Revoked / 38102 / Thawte Points Transfer / 0
-> ok


=> all ok


x1) Full text is:
Project-Id-Version: CAcert
Production Report-Msgid-
Bugs-To: translationsadmin@
cacert.org
POT-Creation-Date:
2012-09-17 10:51+0200
PO-Revision-Date:
YEAR-MO-DA HO:MI+ZONE
Last-Translator: FULL NAME
Language-Team: LANGUAGE
Language: en
MIME-Version: 1.0
Content-Type: text/plain;
charset=UTF-8
Content- Transfer-Encoding: 8bit
X-Generator: Translate Toolkit 1.9.0

(0003253)
Uli60   
2012-10-16 13:36   
see report http://bugs.cacert.org/view.php?id=1101#c3252
(0003268)
Uli60   
2012-10-23 22:39   
1054.5.1 test scenario
---------
created new account Bug1054.5.1.user1@w.d
verified

set flags board, tverify on an admin user
login
assure someone Bug1054.5.1.User1@w.d

only f2f or ttp available as selection
no tverify

https://cacert1.it-sls.de/tverify/index.php
file not found

=> ok
(0005368)
felixd   
2015-04-07 20:08   
A patch is here: (including www/index.php) https://github.com/yellowant/cacert-devel/commits/bug-1054


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1039 [Main CAcert Website] web of trust minor have not tried 2012-05-12 16:01 2021-08-25 13:37
Reporter: INOPIAE Platform: Y  
Assigned To: OS:  
Priority: high OS Version:  
Status: needs review & testing Product Version: 2006  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version: 2006  
    Target Version:  
Reviewed by:
Test Instructions: Ggh
Summary: Cyber peretas nomor 085823771018
Description: Cyber muslim
Tags:
Steps To Reproduce: Tfj
Additional Information: Yghh
Attached Files: cap-1.pdf (27,636 bytes) 2012-05-12 20:34
https://bugs.cacert.org/file_download.php?file_id=258&type=bug
cap.pdf (27,473 bytes) 2018-12-16 12:37
https://bugs.cacert.org/file_download.php?file_id=462&type=bug
Notes
(0002993)
MarekMazur   
2012-05-12 18:33   
"Program Uwierzytelniania CAcert
Formularz Weryfikacji To¿samo¶ci"
instead of
"Program Uwierzytelniania CAcert
Formularz Weryfikacji Tożsamości"

"O¶wiadczenie Kandydata"
should be
"Oświadczenie Kandydata"

"Imiê i Nazwisko:"
should be:
"Imię i Nazwisko:"

"Zgadzam siê z CAcert Community Agreement."
should be:
"Zgadzam się z CAcert Community Agreement."

"Okazane Dokumenty To¿samo¶ci ze zdjêciem:"
should be:
"Okazane Dokumenty Tożsamości ze zdjęciem:"

"Miejsce Spotkanie Twarz± w Twarz:"
should be:
"Miejsce Spotkania Twarzą w Twarz:"

"Jestem cz3onkiem spo3eczno¶ci CAcert, zda3em Assurance Challenge, i posiadam conajmniej 100 pkt potwierdzenia."
should be:
"Jestem członkiem społeczności CAcert, zdałem Assurance Challenge i posiadam nie mniej niż 100 pkt wiarygodności."

Also when name contain character from encoding other than iso8859-1 there is also a problem.

Account with name(s) containing non-latin1 characters are not useable.
(0002994)
mat_64   
2012-05-12 20:43   
In the Dutch version there are some inconsistencies: Capitalisation, Use of words, among others. See attached file.
(0002995)
INOPIAE   
2012-05-12 21:00   
Taken from a mail of Guy Scharinger

Hello everybody,

no default detected in the CAP form in French

Cordialement

Guy Scharinger
(0002996)
jjamor   
2012-05-13 12:30   
In the spanish version, I've not seen any special letter problem.

However, a word is not well translated: "veridicado" should be written "verificado".

In pottle terminology, it is correct (verified = verificado)
(0005714)
alkas   
2018-12-16 12:37   
Czech generated version is completely unusable - most letters with diacritic signs are missing! See the example.
(0005739)
Ted   
2019-01-18 21:17   
This issues occur when languages use non cp-1252 characters, like the eastern european (czech, polish, ...).

We should probably use the UTF-8 version of the FPDF library: http://www.fpdf.org/en/script/script92.php
(0005882)
Adakah   
2020-05-12 18:24   
Hhh


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1025 [Main CAcert Website] misc minor always 2012-03-22 13:51 2021-08-25 13:36
Reporter: Uli60 Platform:  
Assigned To: NEOatNHNG OS:  
Priority: normal OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: NEOatNHNG, BenBE
Test Instructions:
Summary: Domain Dispute strange behaviour / Domain Dispute issue
Description: The problem is taken from ticket [s20120322.56 ] Domain dispute fallout?

A few days ago I used the "Domain Dispute" tab on the CAcert.org website
to "take" domain.tld away from User2, as I was
under a time crunch to get some certs rolled. Before I did this User2
and I were unable to connect to arrange this some other way.

While this got the domain.tld account transferred to me,
User2 tells me it also messed up the other certs for domains he manages
(both domain2.tld for us and several of his personal domains). If I
understood correctly, it also prevented him from logging in to his
cacert account.

Do I understand correctly?

If this is the case, did I miss a warning about the effect my clicking
on "Domain dispute" would have? My only goal was to get
domain.tld transferred to me so I could issue some certs,
and I would have never clicked on that link if I had known that one of
the consequences of that action would have been to affect User2's CAcert
account or the other certificates he had been issued.
Tags:
Steps To Reproduce:
Additional Information: bug# generated for analyze and to reproduce reported problem
Attached Files:
Notes
(0002887)
Uli60   
2012-03-22 15:03   
pre-set
-------
user1
  email: user1@domain1.tld


user2
 email: user2@domain1.tld
   clientcerts: user2@domain1.tld
 domain: domain1.tld
   servercerts: cert1.domain1.tld
                 cert2.domain1.tld
 domain: sub1.domain1.tld fail
   servercerts: cert1.sub1.domain1.tld -
                 cert2.sub1.domain1.tld -
 domain: domain2.tld
   servercerts: cert1.domain2.tld
                cert2.domain2.tld
 domain: sub1.domain2.tld fail
   servercerts: cert1.sub1.domain2.tld -
                cert2.sub1.domain2.tld -

test procedure
--------------
created user1 and user2
both verified
both accounts assured upto 100 assurance points
loggedin user2
create client cert
adding domain domain1.com
confirm email probe (postmaster@), under ca-mgr1 under bug1025.user2 account email

adding domain sub1.domain1.tld
email probe to: postmaster@sub1.domain1.tld results in error:
"Email Address given was invalid, or a test connection couldn't be made to your server, or the server rejected the email address as invalid
Failed to make a connection to the mail server"
Bug? Fallback to postmaster@domain1.tld is impossible

adding domain domain2.de
confirm email probe (postmaster@), under ca-mgr1 under bug1025.user2 account email

adding domain sub1.domain2.tld
email probe to: postmaster@sub1.domain2.tld results in error:
"Email Address given was invalid, or a test connection couldn't be made to your server, or the server rejected the email address as invalid
Failed to make a connection to the mail server"

sub domains failed email probe, cannot be tested

creating 4 server certs private keys and csr's with openssl,
2 each for domain1.tld and domain2.tld

signing all 4 csr's with class3 testserver subroot
1. server1.domain1.com serno 10AF
2. server2.domain1.com serno 10B0
3. server1.domain2.de serno 10B1
4. server2.domain2.de serno 10B2

logout

login user1
domain add domain1.tld
error: The domain 'domain1.com' is already in a different account and is listed as valid. Can't continue.
=> OK

Dispute Abuses
 + Domain Dispute

warning message:
"If your dispute is successful the domain will be removed from the current account and any certificates will be revoked."

Please choose an authority email address
  postmaster@domain1.com
click -> "Update Dispute"

system message:
"The domain 'domain1.com' has been entered into the dispute system, the email address you choose will now be sent an email which will give the recipent the option of accepting or rejecting the request, if after 2 days we haven't received a valid response for or against we will discard the request."


ca-mgr1: login to user2
6 new emails:
1. [CAcert.org] Dispute Probe
2.-6. [CAcert.org] Your Certificate is about to expire

text of 1)
You have been sent this email as the domain 'domain1.com' is being disputed. You have the option to accept or reject this request, after 2 days the request will automatically be discarded. Click the following link to accept or reject the dispute:
https://cacert1.it-sls.de/disputes.php?type=domain&domainid=167973&hash=e2d8f99e5acff58421b8be6fcd0a6671

text of 2-6)
Your certificate is set to expire in approximately 30 days time, ...
(this relates to the shortened timeframe test certs expires within 1 week or 1 month) => OK
doesn't relate to the domain dispute


login user2 to testserver

client certs view: 1 listed
domains view: 2 domains listed
server certs view: 4 server certs listed
=> OK (at this stage)

accepting dispute
Domain Dispute
Reject Dispute
Accept Dispute <=
Report Dispute as Abuse
click -> "update dispute"

system message:
"You have opted to accept this dispute and the request will now remove this domain from the existing account, and revoke any current certificates.

The following accounts have been removed:
domain1.com"


server certs view: 2 server certs listed for domain2.de (serno: 10B1, 10B2)
domains view: 1 domain listed, domain2.de
client certs view: 1 client cert listed user2@domain1.com (!)


=> OK

logout

login user1
domain view: 0 domains listed

add domain: domain1.com
confirming email probe
view domains: domain1.com listed

=> OK

==> original bug report cannot be confirmed, cannot be reproduced on testserver
(0002888)
MarekMazur   
2012-03-22 22:49   
Please to check this case:
1. user1 - 2+ e-mail accounts, no domains assigned; user2 - whatever.
2. Try e-mail dispute on user1 primary account.
3. user1 accept e-mail dispute.

Code that is interesting:

$rc = mysql_num_rows(mysql_query("select * from `domains` where `memid`='$oldmemid' and `deleted`=0"));
                    $rc = mysql_num_rows(mysql_query("select * from `email` where `memid`='$oldmemid' and `deleted`=0 and `id`!='$emailid'"));
                    $res = mysql_query("select * from `users` where `id`='$oldmemid'");
                    $user = mysql_fetch_assoc($res);
            if($rc == 0 && $rc2 == 0 && $_SESSION['_config']['email'] == $user['email'])
            {
                mysql_query("update `users` set `deleted`=NOW() where `id`='$oldmemid'");
                echo _("This was the primary email on the account, and no emails or domains were left linked so the account has also been removed from the system.");
            }
I have no clue what $rc2 is reffering to...
(0002889)
Uli60   
2012-03-22 23:25   
(Last edited: 2012-03-22 23:51)
strike "or domains" :D
compare it to line 271 + 272 of /www/disputes.php

/www/disputes.php l. 75 + 76 probably should be:
$rc = mysql_num_rows(mysql_query("select * from `domains` ...
$rc2 = mysql_num_rows(mysql_query("select * from `email` ...

at least this is a bug, but doesn't relate to the reported issue
if not wrongly clicked the EMAIL dispute instead of DOMAIN dispute.
The answer can give user2 by forwarding line 1 of the email user 2 received for acceptance of the dispute, as this email line includes the text about the dispute method: -> EMAIL dispute -or- DOMAIN dispute

reason why EMAIL dispute cannot delete an account if account has > 1 email address defined is /www/disputes.php line 271 - 279 code, that prevents removal of one email definition, if its not the only one email address left in the account.

(0002890)
MarekMazur   
2012-03-22 23:39   
I don't get 'probably' part of your comment Uli. :)

My simply guessing is that user1/2 is afraid of consequences and lies about that he used a domain dispute and sent email dispute instead.

We won't ever know if someone don't check in database that there exist a deleted account referring to user1 e-mail address.

If user2 lies, looking for reason of this bug is a waste of time.
(0002891)
MarekMazur   
2012-03-23 01:13   
Ulrich, note that it is required for account to be empty only to start this process, finishing this process is not checking one of the requirements.
(0002991)
NEOatNHNG   
2012-05-08 21:32   
I have fixed the $rc issue, please check whether the original bug is also fixed. Please test & review.
(0003073)
BenBE   
2012-06-19 19:02   
The patch looks sane and should fix the above mentioned problem. Reconstructing from the original source there really COULD be the situation when disputing the primary email address could lead to account removal even if there were still domains on that account left. This situation SHOULD be fixed with this patch.
(0003348)
BenBE   
2012-11-20 20:27   
The patch is okay and addresses the issue.

Though the coding style could be better in cases of e.g. database errors - the code gives the correct result, but passing unchecked resource handles to mysql_num_rows is clearly bad style.
(0003370)
Uli60   
2012-11-28 02:30   
7 users generated
bug1025.user0@w.d .. bug1025.user6@w.d


prepared:
       1 email 2 email 0 domains 1 domain 2 domains test-domains

user1 + + behappy
user2 + + morgen
user3 + + risipisi, bauwagen
user4 + + einmal, support
user5 + +
user6 + +


login bug1025.user0@w.d
dispute user1 domain
The domain 'behappy' has been entered into the dispute system, the email address you choose will now be sent an email which will give the recipent the option of accepting or rejecting the request, if after 2 days we haven't received a valid response for or against we will discard the request.

login to ca-mgr1 for user1, mail received:

You have been sent this email as the domain 'behappy' is being disputed. You have the option to accept or reject this request, after 2 days the request will automatically be discarded. Click the following link to accept or reject the dispute:

https://cacert1.it-sls.de/disputes.php?type=domain&domainid=167995&hash=963ef3d1d5be963beb817f5e5731e390

3 options:
Reject Dispute
Accept Dispute <===
Report Dispute as Abuse

You have opted to accept this dispute and the request will now remove this domain from the existing account, and revoke any current certificates.

The following accounts have been removed:
behappy

view Domains: empty => ok
view email: 1 email => ok

user0:
view domains: no domains => ok
view emails: 1 email => ok

add domain -> behappy
confirmation
view domains: 1 domain => ok


dispute email user1

You have opted to accept this dispute and the request will now remove this email address from the existing account, and revoke any current certificates.

The following accounts have been removed:
bug1025.user1@w.d
This was the primary email on the account, and no emails or domains were left linked so the account has also been removed from the system.
=> ok

user0:
view domain: 1 => ok
view email: 1 => ok

add new email (user1), confirmed
view domain: 1 => ok
view email: 2 => ok

test series 1 => ok
-----

login user0
dispute user2b email, user2: accept dispute

user0
view domain: 1 => ok
view email: 2 => ok
add email user2b, confirmed

view domain: 1 => ok
view email: 3 => ok

(user2: 1 domains, 1 email left)

dispute last email from user2

results in:
You only dispute the primary email address of an account if there is no longer any email addresses or domains linked to it. => ok

dispute domain from user2, accepted

user0:
view emails: 3 => ok
view domains: 1 => ok

add domain 'morgen', confirmed

user0:
view emails: 3 => ok
view domains: 2 => ok

dispute last email from user2, accepted

user0:
view emails: 3 => ok
view domains: 2 => ok

add email (user2), confirmed
user0:
view emails: 4 => ok
view domains: 2 => ok

trying to login to user2 ->
Incorrect email address and/or Pass Phrase. -> ok (as expected)

login to admin account, search user2 email
Sysadmin - find user -> user2
shows bug1025.user0@w.d => ok
emails shown as Secondary Emails (3), 2 domains => ok

test series 2 => ok
-----

series3: user3 + + risipisi, bauwagen

login user0:
disputing 2 domains, 1 email (in this order, email: bug1025.user3@w.d)
You only dispute the primary email address of an account if there is no longer any email addresses or domains linked to it.

ca-mgr1 login to user3
dispute probe for 2 domains found, accepting both

user3: 0 domains remaining, 1 email remaining
user0: restart email dispute, accepted

user0:
add 2 domains, 1 email
ca-mgr user0: 3 probe emails -> 2 domains, 1 email, all 3 confirmed

user0:
view emails: 5 => ok
view domains: 4 => ok

test series 3 => ok
-----

series 4:
user4 2 email 2 domains einmal, support

user0: dispute 2 domains, 1 secondary email, accepted by user4 (ca-mgr1 emails)
user0: dispute last primary email, accepted by user4

user0: add 2 free'ed emails, add 2 free'ed domains

user0:
view emails: 7 => ok
view domains: 6 => ok

test series 4 => ok
-----

summary
email dispute of primary email cannot pass
(message: You only dispute the primary email address of an account if there is no longer any email addresses or domains linked to it.)
if secondary email addresses or domains still remains under an account
(0003380)
INOPIAE   
2012-12-08 08:28   
(Last edited: 2012-12-08 10:29)
While testing I found five major errors:
- Why is there no automatic log out of the account if the primary address is disputed successfully?
- When disputing an email address from a German account the subject is somehow cryptic, when disputing it from an English account it shows a proper subject.
German: =?utf-8?B?W0NBY2VydC5vcmddIMOcYmVydHJhZ3VuZ3NhbmZyYWdl?=
English: [CAcert.org] Dispute Probe
- When I am logged in with account 1 and I use the confirmation link send to account 2 the dispute process works.
The dispute process should only work with the account where the confirmation link is send to.
- There is no information how the responded of the dispute reacted. There should be a mail send to the requestor.
- It is possible to delete an account that has given assurances via the dispute method. This should definitly not be allowed. If the account just got assured it may be possible.

Nice to have have the disputing message in the language of the reciepient.

Test:

Removing the address from an account that only has an primary email address.

Requesting account shows (message1):
The email address 'xxx@yyy.tt' has been entered into the dispute system, the email address will now be sent an email which will give the recipent the option of accepting or rejecting the request, if after 2 days we haven't received a valid response for or against we will discard the request.
=>ok

Dispute account gets mail with this text (message2):
You have been sent this email as the email address 'xxx@yyy.tt' is being disputed. You have the option to accept or reject this request, after 2 days the request will automatically be discarded. Click the following link to accept or reject the dispute:

https://cacert1.it-sls.de/disputes.php?type=email&emailid=244644&hash=61a54aa79ff7d48c3358abd3ecf30de5

Best regards,
CAcert.org Support!

=>ok

After following the link you see this (message3):
Currently the email 'xxx@yyy.tt' is in dispute, you have been sent an email to resolve the issue, below you have the option to accept, reject or report the request as fraudulent.

Reject Dispute
Accept Dispute
Report Dispute as Abuse

=>ok

When using Reject Dispute this is displayed (message4)
You have opted to reject this dispute and the request will be removed from the database
=>ok
Account stays =>ok

When using Accept Dispute this is displayed (message5)
You have opted to accept this dispute and the request will now remove this email address from the existing account, and revoke any current certificates.
The following accounts have been removed:
xxx@yyy.tt

This was the primary email on the account, and no emails or domains were left linked so the account has also been removed from the system.
=>ok
Account deleted=>ok
 
When using Report Dispute as Abuse the forwared to https://cacert1.it-sls.de/disputes.php. What happens?
Disputed 4.1025@acme.com from 0.1025@acme.com on 2012-12-08 10:30

Just disputing without any action: What happens?
Disputed 5.1025@acme.com from 0.1025@acme.com on 2012-12-08 10:30

Removing the primary email address from an account that hold at least on other email address or an domain:

Requesting account shows (message6):
You only dispute the primary email address of an account if there is no longer any email addresses or domains linked to it.
=>ok Text could be more percise.
Nothing happens =>ok

Removing the an email address from an account that hold at least two email addresses:
Requesting account shows message1=>ok
Dispute account gets mail with message2=>ok
After following the link you see message3=>ok
When using Reject Dispute message4 is displayed=>ok
When using Accept Dispute this is displayed (message7)
You have opted to accept this dispute and the request will now remove this email address from the existing account, and revoke any current certificates.

The following accounts have been removed:
xxx@yyy.tt
Text must be the "the following email address has been removed:"
Text fails, Action is correct, email address removed
=>partly fail

Removing the a domain from an account that hold at least one email addresses and one domain:
Requesting account shows this (message8):
Please choose an authority email address ...
=>ok
After hiting update dispute shows this (message9):
The domain 'yyy.tt' has been entered into the dispute system, the email address you choose will now be sent an email which will give the recipent the option of accepting or rejecting the request, if after 2 days we haven't received a valid response for or against we will discard the request.
=>ok

Dispute account gets mail with this text (message10):
You have been sent this email as the domain 'yyy.tt' is being disputed. You have the option to accept or reject this request, after 2 days the request will automatically be discarded. Click the following link to accept or reject the dispute:

https://cacert1.it-sls.de/disputes.php?type=domain&domainid=168008&hash=040315ff58fdc51001bc69b5f53eefa4

Best regards,
CAcert.org Support!
=>ok
After following the link you see this (message11):
Currently the domain '1025.inopiae.com' is in dispute, you have been sent an email to resolve the issue, below you have the option to accept, reject or report the request as fraudulent.
=>ok
When using Reject Dispute message4 is displayed=>ok
When using Accept Dispute this is displayed (message13):
You have opted to accept this dispute and the request will now remove this domain from the existing account, and revoke any current certificates.

The following accounts have been removed:
yyy.tt
Text must be the "the following domain has been removed:"
Text fails, Action is correct, email address removed
=>partly fail

(0003381)
INOPIAE   
2012-12-08 10:32   
Needs definitly work see major errors discribed in
https://bugs.cacert.org/view.php?id=1025#c3380
(0003748)
Uli60   
2013-02-12 22:02   
(Last edited: 2013-02-12 22:14)
- When disputing an email address from a German account the subject is somehow cryptic, when disputing it from an English account it shows a proper subject.
German: =?utf-8?B?W0NBY2VydC5vcmddIMOcYmVydHJhZ3VuZ3NhbmZyYWdl?=
English: [CAcert.org] Dispute Probe

problem in ca-mgr1 (TMS)
that doesn't handle utf8 subject lines correctly, but email clients do
see https://bugs.cacert.org/view.php?id=932

(0003750)
Uli60   
2013-02-12 22:17   
- It is possible to delete an account that has given assurances via the dispute method. This should definitly not be allowed. If the account just got assured it may be possible.
from https://bugs.cacert.org/view.php?id=1025#c3380 report

possible simple solution:
check if count(assurances-given) > 0
  then throw exception: automated dispute impossible, file dispute by sending dispute email to support@c.o
(0005446)
BenBE   
2015-08-09 21:06   
The second issue in comment 3380 mentioned by INOPIAE has been addressed via a fix to issue 0000932 on the TMS/ca-mgr1.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
991 [Main CAcert Website] my account minor always 2011-10-18 20:08 2021-08-25 13:36
Reporter: Marek Mazur Platform: x86_64  
Assigned To: NEOatNHNG OS: Linux  
Priority: normal OS Version: 3.1.0-0.rc9.git0  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: commonName is wrongly burned on CSR
Description: Everything after quoted name is ommited in CSR. Certificate is signed by signer.

For example:
"Bartłomiej Skrzynia" will generate CSR for "Bart&".

The worst part: signer signs this kind of certificates.
Tags:
Steps To Reproduce: 1. Change your name to name containing character not from latin1 charset.
2. Generate CSR.
3. openssl x509 -in your_certificate -noout -issuer -subject
Additional Information:
Attached Files:
Notes
(0003462)
Uli60   
2012-12-18 22:07   
rfc standards:
rfc 4880, defaults to utf-8, section 5.11
email rfc-2822


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
979 [Main CAcert Website] minor always 2011-09-04 23:17 2021-08-25 13:35
Reporter: NEOatNHNG Platform: Main CAcert Website  
Assigned To: BenBE OS: N/A  
Priority: normal OS Version: stable  
Status: needs feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: NEOatNHNG
Test Instructions:
Summary: HTML <meta> tag states charset=utf-8 on some pages when it is not
Description: There are some pages (known: account.php, maybe more) where the HTML meta tag declares the Content-Type to be "text/html; charset=utf-8" when in fact we always use ISO-8859-1 (aka latin1) as encoding (at least for values from the data base).

This error doesn't show because the web server explicitly sets a content type header of it's own and therefore overwrites the setting but it's wrong nevertheless.
Tags:
Steps To Reproduce:
Additional Information: Maybe remove the meta tag alltogether because it is not in effect anyway?
System Description Production version of the CAcert website
Attached Files:
Notes
(0002403)
jandd   
2011-09-05 08:38   
Wouldn't it be much better to use UTF-8 everywhere (I know that this is not possible with the current codebase). I see the problem that we are not able to handle non-Latin character sets if we stick with ISO-8859-1. Cyrillic and asian character sets are use by a huge share of the world population and we should not force everyone to transliterate their names to latin characters.
(0002408)
NEOatNHNG   
2011-09-05 13:58   
(Last edited: 2011-09-05 14:00)
Yes, transitioning to UTF-8 would be great but is very complicated with the current code base, as you mentioned. Non-latin1 characters can be entered though. They are escaped as HTML entities by the browser AFAIK. For now we should at least fix our software so that latin1 is handled correctly we then have to do a big master plan how to move on.

(0002638)
MarekMazur   
2011-10-25 01:14   
And this HTML entities are causing problems with generating certificates/signing PGP keys for people with diffrent-than-english-or-german charset.
(0004637)
NEOatNHNG   
2014-03-11 23:55   
Apparently the account_stuff.php was the only relevant part where this would cause problems. Fixed. Please test and do a second review.
(0004687)
BenBE   
2014-03-27 07:19   
I still see some forms which are posted utf-8 when the pages themselves are latin1. While by the standard this is perfectly valid it usually causes problems with some browsers when they need to decide which of various conflicting charset values to use - usually they will use the wrong one.

Thus we should convert the codebase to UTF-8 and tell so in the returned documents. Given the numerous occations we currently have to do charset conversions it would be much simpler if those would be reduced to basically Charset Normalization and Escaping.

Review NACK.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
932 [test.cacert.org] test.cacert.org minor have not tried 2011-05-07 17:38 2021-08-25 13:35
Reporter: abheiden Platform:  
Assigned To: BenBE OS:  
Priority: normal OS Version:  
Status: needs testing Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Get UTF8 failured email subject
Description: The subject was "=?utf-8?B?W0NBY2VydC5vcmddIFlvdSd2ZSBiZWVuIEFzc3VyZWQu?="

Content:
You are receiving this email because you have been assured by Atona Çodelu (guide@galaxy.net).

You were issued 100 points however the system has rounded this down to 10 and you now have 10 points in total.

Best regards
CAcert Support Team
Tags:
Steps To Reproduce:
Additional Information: Testserver system is an enclosed environment, no mails can be sent out from the testserver. Mail delivery is completely blocked by the testservers firewall.

This is either
a) to prevent unwanted illegitimate use our testserver by spammers
b) to prevent conflicts in sending mails with the production server

But some tests requires sending of mails, to check if mails are sent, and if the content relates to the proposed content. At least in the create an account routine, also on adding a domain, the tester has to await an email for confirmation of the triggered action.

Also some other activities needs to be handled similiar to a console access
(set flags on user accounts, add assurance points over an account).
So therefor we've deployed the Testserver-Management-System - short TMS
that includes administrative functions to manage accounts and also a simple mail viewer, to read "received" mail content for a specific user under testing.

The mail viewer is no real mail client. This mail viewer is only a workaround that content of mails can be displayed (eg the confirmation string that is needed to confirm an account creation).
The mail viewer cannot handle crypted mails, binhex, Base64 mails, s/mime mails, only raw text is displayed. No internet headers will be displayed, and also the subject handling has no conversion routines implemented.

If someone feels compfortable to program a real working mail client under zend-framework (the TMS is build on), please feel free :)
The source is available under the git repository git-cacert.it-sls.de
as cacert-mgr.git

Attached Files:
Notes
(0003516)
Werner Dworak   
2012-12-21 05:14   
More than 3 month fixed and no complaints
(0003749)
Uli60   
2013-02-12 22:06   
(Last edited: 2013-02-12 22:12)
https://bugs.cacert.org/view.php?id=1025#c3380
problem persists
should be fixed anyway, but has low priority
fix has to be an update to zend framework / mail routines under TMS / ca-mgr1

(0005444)
INOPIAE   
2015-08-09 16:28   
I pushed a fix to https://github.com/INOPIAE/cacert-testmgr/commit/4e3199d62fc2143da34fa6671e17f3eec6e576c8
(0005452)
INOPIAE   
2015-08-20 19:14   
I pushed a new fix to https://github.com/INOPIAE/cacert-testmgr/commit/9987c02e3e9e8f1d9b6219c1384297036c583da7
(0005461)
INOPIAE   
2015-09-08 20:32   
I pushed a new fixed to https://github.com/INOPIAE/cacert-testmgr/commit/2239f970eacd9205b19f532d6fcc53b70c4d3e14


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
869 [Wiki] major always 2010-09-29 06:48 2021-08-25 13:34
Reporter: INOPIAE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Wrong characters while creating the pdf for COAP
Description: While using an "ä" in the COAP-HTML-Form (http://wiki.cacert.org/CoapHTML?highlight=%28COAP%29) this is displayed in the new created pdf-file as "ä"
Tags:
Steps To Reproduce:
Additional Information: OS Windows 7, IE8.0 and Firefox 3.6
Attached Files:
Notes
(0001847)
INOPIAE   
2011-01-26 14:33   
I found out, that if I turn the codepage to Windows Westeren Europe the special characters work, if the codepage is UTF-8 is does not show the special Characters.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
610 [CATS.cacert.org] User Interface feature always 2008-09-13 04:24 2021-08-25 13:34
Reporter: jandd Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: use utf-8 as encoding
Description: Use utf-8 as encoding for all user visible strings to open the possibility to translate to non latin languages.
Tags:
Steps To Reproduce:
Additional Information: Having unix style NL-only line endings would be nice too (saves space and the production system is using Linux anyway).
Attached Files:
Notes
(0001208)
bigon   
2008-09-24 08:31   
Yeah using utf8 everywhere would be nice. Translingo is using utf8 as encoding that could cause some issues when saving strings with non-ascii chars
(0001210)
jandd   
2008-09-25 19:56   
Using UTF-8 could cause trouble with legacy data in the database. So implementing it in the front end code is not enough. A database conversion script must be implemented too. Maybe a dump and restore with a recode in between will work ... needs testing though.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
475 [CATS.cacert.org] Database trivial always 2008-01-05 00:36 2021-08-25 13:34
Reporter: evaldo Platform: Default  
Assigned To: Ted OS: any  
Priority: low OS Version: any  
Status: needs work Product Version: production  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Improvements on some tables
Description: Table user:

We should have an issuer table with a list of our roots, and only the root_id on the user table. This allows for future expansion, and for third-party use. Remember CAcert is going to release its code as open-source.

  `root` set('CA Cert Signing Authority','CAcert Class 3 Root') collate latin1_general_ci NOT NULL default '',
should be changed with a foreign relation to the issuer table.

LANG doesn't always come in 2-letter flavours, for example "pt_BR.ISO8859-1". We are kinda breaking ISO here, which is a bad idea :)
  `lang` char(2) collate latin1_general_ci NOT NULL default '',

Database encoding should be changed to UTF-8 to allow non-ascii-writing people to use the system. Think asia!

Table topics:

numOfQu shouldn't exist like that. we should count() questions for that topic instead. Desyncs are bad!


Table learnprogress:

root -> see table user comments
percentage as decimal(5,0): I wonder who can do 99999.00% of it right ;) decimal with 0 decimal positions is a misuse -> try int ;)



All Tables:

We should use BOOL (BOOLEAN) type instead of enum, to avoid the conversion overhead.

MySQL 5 Reference:
"BOOL, BOOLEAN

These types are synonyms for TINYINT(1). A value of zero is considered false. Non-zero values are considered true: "
Tags:
Steps To Reproduce:
Additional Information:
System Description Default profile.
Attached Files:
Notes
(0000988)
evaldo   
2008-01-05 01:02   
Bug 0000472 comment 982 reminded me to comment about "Not Null" statements that should be on all collumns on all tables unless there REALLY is a meaning for that collumn being null.
(0000990)
evaldo   
2008-01-05 01:34   
Bug 0000465 suggests the lack of unique constraints/indexes needed to eliminate problems with duplicate records automatically
(0000995)
MichelleStahl   
2008-01-09 14:02   
>>Table topics:

>>numOfQu shouldn't exist like that. we should count() questions for that topic >>instead. Desyncs are bad!

numOfQu doesn't count the questions of a topic.
Here is stored how many questions a test of this topic has.
p.e.
Topic 1 : numOfQu=5
Topic1 has 5 questions per test.

Maybe it is named unfortunately.
I think we should rename it.
(0000998)
Ted   
2008-01-13 20:59   
(Last edited: 2008-01-13 21:00)
RFC 3046 (http://tools.ietf.org/html/rfc4646#section-4.3) recommends a buffer length of at least 42 characters for language tags.
Since I don't think that this will lead us into storage problem we should adher to this (though I doubt we'll really use even 10 characters).

(0003580)
Werner Dworak   
2012-12-29 05:29   
At present shelved


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1442 [Main CAcert Website] misc minor N/A 2018-10-20 20:57 2021-08-07 21:32
Reporter: Ted Platform: Default  
Assigned To: GuKKDevel OS: any  
Priority: high OS Version: any  
Status: needs review & testing Product Version:  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Rewrite code to use ext/mysqli API (or PDO_MySQL) instead of ext/mysql
Description: As reported by Wytze in https://wiki.cacert.org/AGM/TeamReports/2018 :

[...] An upgrade to Debian Stable is not possible with the current PHP code base, due to its dependency on an obsolete mySQL database interface layer, which is not supported anymore in the PHP version bundled with Debian Stretch, the current Debian Stable.

Without the ability to upgrade the application platform to a well-maintained version of Debian, the Critical System Administrator Team will be unable to take responsibility in the near future for the safe and correct operation of CAcert's main server, the web application and database server.
Tags:
Steps To Reproduce:
Additional Information: Currently ext/mysql is used. A look at https://secure.php.net/manual/en/mysqlinfo.api.choosing.php seems to imply that ext/mysqli is more closely related to ext/mysql than the alternative PDO_MySQL.

If you think that migrating to PDO_MySQL is less work, you're welcome to do it, I've no strong feelings about this.
System Description Default profile.
Attached Files: origin_release (88,558 bytes) 2018-10-26 17:56
https://bugs.cacert.org/file_download.php?file_id=433&type=bug
origin_bug-1260 (71,163 bytes) 2018-10-26 17:56
https://bugs.cacert.org/file_download.php?file_id=434&type=bug
diff-release-bug1442 (361,098 bytes) 2018-10-30 22:19
https://bugs.cacert.org/file_download.php?file_id=435&type=bug
diff-bug-1442-newTarballs (9,392 bytes) 2018-10-31 06:09
https://bugs.cacert.org/file_download.php?file_id=436&type=bug
Notes
(0005615)
GuKKDevel   
2018-10-26 17:56   
I did a text-check for "mysql_" on the CAcert-devel-directory with release checked out and a text-check for "mysqli_" with bug-1260 checked out.
(0005618)
Ted   
2018-10-28 21:41   
We re-open this and use this case to handle only the mysql migration part of 0001260
(0005624)
GuKKDevel   
2018-10-30 22:19   
I did some coding. all mysql_-statements replaced by the according mysqli_-statements.
(0005626)
GuKKDevel   
2018-10-31 06:09   
adding files from new tarballs
(0005685)
Ted   
2018-11-18 14:45   
GuKK, I noticed two typos:
- includes/notary.inc.php line 1202: mmysqli_query should probably start with only one "m"
- scripts/58at-ate-wien-mail.php.txt line 117: dto.
(0005689)
Ted   
2018-11-26 22:48   
bug-1442 is merged into branch the integration branch (resulting in branch test-1442) for testing. Currently test-1442 is installed on both, old and new, testservers (https://test.cacert.org/ and https://test3.cacert.org:14943/)

Note that test3 is not yet completely installed, so it's more for playing around. Test reports from test.cacert.org are welcome!
(0006012)
Ted   
2021-06-08 21:42   
The System Admin console whas mostly broken, all actions which did write in table AdminLog did not work.

I located the problem in includes/notary.inc.php, function write_se_log. I'm not sure how this could happen (@GuKKDevel, maybe you can have a look?), but in fact an undefined function g() was called...

Comitted the fix as bd240d31200c621c0c16381bd99b47b9b1a8d45c to bug-1442
(0006071)
Ted   
2021-08-07 21:32   
@jandd has created pull request 0000021 (already end of 2020) in github which sounds like it is a more extensive replacement of the old API... This needs more evaluation!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
666 [bugs.cacert.org] misc minor always 2009-01-03 20:22 2021-08-07 20:39
Reporter: ph3 Platform: Main CAcert Website  
Assigned To: OS: N/A  
Priority: normal OS Version: stable  
Status: new Product Version: production  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mantis allows login without SSL/TLS
Description: Mantis allows to login without SSL/TLS. You need to manually add the s for SSL/TLS into the location bar of your browser.
Tags:
Steps To Reproduce:
Additional Information: Possible fix:

check for protocol (HTTP/HTTPS) and redirect to https://$HOST/$SCRIPT?$QUERY_STRING in case if HTTP. As it will mainly redirect on the login page this should not break something.
System Description Production version of the CAcert website
Attached Files: rfc3330.txt (16,200 bytes) 2014-10-04 09:53
https://bugs.cacert.org/file_download.php?file_id=382&type=bug
Notes
(0001265)
Sourcerer   
2009-01-04 19:35   
The possibility to login without HTTPS is a feature, not a bug. (So that people that have troubles with importing the root certificate can also file bugs)
The default login with HTTP is a bug, we would prefer to default to HTTPS login.
Could you evaluate, whether we can configure that in Mantis, and if not to file a feature request for that feature on http://www.mantisbt.org/
(0005543)
bjobjo   
2017-04-04 16:29   
Hi,

The confirmation mail when you register in Mantis redirects you to the non-secure access where you have to define your password.

Please change all links to https.

I don't agree for "possibility to login without HTTPS is a feature",
this is probably a very specific case, you can still offer a redirect page that displays information and a link to a form specific for this kind of problems and a link to the secure site. A FAQ about "cannot access the https site" can also be present on that form to help the user and avoid ticket if he did not import the root certificate (which is not anymore sufficient as firefox is refusing MD5/RSA signed certificates in the full chain as stated in ticket 0001305).

So please, secure all our sites and make it state of the art.

Thanks a lot for the hard work!
(0006043)
Ted   
2021-08-05 18:29   
I just tried, and it seems to have been fixed... Please someone else check it before we can close it...
(0006046)
alkas   
2021-08-05 19:38   
I just have tried too, but probably because I have CAcert roots installed, the http://... immediately changed to https://...
(0006052)
Golffies   
2021-08-06 10:27   
@Alkaš: To restore access to the http version of the site, you need to reset the "site preferences" kept by Firefox. Please see: https://stackoverflow.com/questions/30532471/firefox-redirects-to-https
(0006053)
Ted   
2021-08-06 11:13   
Note that since new users are not able to file bugs anyway (since 2020), the comment of @Sourcerer from 2009 is somewhat obsolete.

IMHO access to the server can be restricted to HTTPS. Most people "file a bug" by mailing to support anyway...
(0006054)
alkas   
2021-08-06 12:55   
My Firefox 90.0.2/64 for Ubuntu reports that the server bugs.cacert.org uses HSTS and forces https://... connection. It also reports that there is nothing I can do. I have set the distrust tu CAcert root, even after that the http:// switched to https://, and the server connection was rejected, as expected. So my conclusion is that anyone is unable to http:// connect as long as HSTS is set on the server.
(0006056)
alkas   
2021-08-06 16:48   
Next try using https://stackoverflow.com/questions/30532471/firefox-redirects-to-https. I must admit that Firefox's talking about HSTS is misleading. After that, I am able to reach bugs.cacert.org with http://, and then I am also able to login. Firefox only says: Unsecured connection. I am also allowed to add this note.
(0006062)
jandd   
2021-08-07 11:02   
Is it still a valid assumption that bug submission via http is a feature (like in the comment from @Sourcerer from 2009)? Do we trust the ISPs/network operators of all of our users or on the way to our systems?

From my point of view we should have a simple way to collect bug reports from users that cannot install CAcert CA certificates but from a privacy point of view this should be secured too (maybe a separate form secured with a letsencrypt server certificate). Redirecting all http access to https would make administration/maintenance easier.
(0006063)
Ted   
2021-08-07 18:01   
Currently, new users are only viewers, not reporters anymore, due to increasing SPAM in form of bug reports.

So, bugs.cacert.org is not open for bug reports of "the general public" anyway. Given this, I'd consider http access to bugs.cacert.org as more or less obsolete. It might be nice for read-only (non-login) access if this is easily possible, but I guess redirecting the whole traffic (as @jandd proposes) will be considerably easier.

But, I don't want to make this decision alone...
(0006066)
alkas   
2021-08-07 19:39   
If I understood well:
1. Restriction to https (needs CAcert roots installed)
2. Reports could be added if an user has a valid client certificate.
3. Reports could be added if an user has no client certs. He could use credentials he has set when he created his account.
Why cannot an user use his account's credentials (username /=email/, and password) ?
(0006067)
Ted   
2021-08-07 19:46   
(Last edited: 2021-08-07 19:48)
@alkas, I don't think you did understand my point. I'll try it a third time.

Currently new users can not create new issues. Not before first contacting a mantis admin at CAcert who must grant them reporter access.

This is not related to the HTTP/HTTPS-issue. Reporting of bugs by new users has been disabled in 2020 because it was abused more and more to post SPAM. But this change obsoletes the reasoning of @Sourcerer, that http (non -s) is needed so "newbies" can create issues.
(0006069)
alkas   
2021-08-07 20:21   
@Ted,
"Not before first contacting a mantis admin at CAcert who must grant them reporter access."
What I tried to do, is only to propose skipping the above step. That step does protect against spam, because a spammer can create an account, then ask Mantis admin, then make spam messages, but reviewers know spammer's identity. If everybody who has an account can add issues, the situation is the same: admin and reviewers know his identity.
I share your points about HTTP/S and spammers creating "issues" via http and no cert.

A related problem: when I want to connect to Bugs, I am asking for a valid client cert at first, Only then I am able to login = to say who I am.
Why is my client certificate insufficient, despite I am assured with 100 AP ? Is it only a technical problem ?
(0006070)
Ted   
2021-08-07 20:39   
@alkas ok, I did not read that from your last comment. Now it seems that we agree in most points. :-)

Probably no newbie will ever contact a mantis admin and ask for right elevation.
Should this happen nevertheless, the mantis admin should ask which error they want to report. If they can give a sensible answer to this question they won't be spammers. At least not in the beginning... Let's wait till AIs can handle that situation and re-evaluate then. ;-)
(BTW, knowing/blocking identities does not really help if these "identities" are throwaway mail addresses)

But, IMHO a more sensible process for newbies having problems would be that they write a mail to support (preferably the mailinglist, which indeed has some active users). If the support mailing list decides that the report is indeed something that belongs into mantis some mailing list user with reporter access (I'm quite sure that there are several) should create the issue.

So, to come back to the current issue, I really do not see the need for HTTP access. People active in the support mailing list should be able to import CAcert's roots.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1306 [Main CAcert Website] certificate issuing major always 2014-09-15 14:25 2021-08-07 19:24
Reporter: wytze Platform:  
Assigned To: GuKKDevel OS:  
Priority: normal OS Version:  
Status: fix available Product Version: 2014 Q3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: expired certificates should not be listed in the CAcert CRLs
Description: The size of the current CAcert Class1 CRL (http://crl.cacert.org/revoke.crl) is 6.5 megabyte. Even the CAcert Class3 CRL (http://crl.cacert.org/class3-revoke.crl) is already 0.75 megabyte. This is causing an unacceptable huge amount of CRL download traffic (currently over 130 GB *per day*). In addition, it is causing verification failures for certain clients, e.g. the Microsoft Crypto API, due to the long time required for downloading the CRL.

The main cause for the large size of the CRLs is the inclusion of *all* certificates revoked since the start of CAcert (in 2003) in there. As a result, most of the certs listed as revoked have expired a long time ago already, and are thus invalid anyway. There is no RFC requirement to include such expired certs in the CRL; omitting them will result in CRLs of a much more manageable size.
Tags:
Steps To Reproduce: The attached logfile shows an example of failure on the Microsoft platform for the command:
    certutil -f -verify -urlfetch -t 30 server.crt
Additional Information: See also http://social.technet.microsoft.com/Forums/windowsserver/en-US/7e69d0d1-1df2-4830-8d22-f887b6261062/cacert-revocation-server-offline?forum=w7itprosecurity
Attached Files: crl-size-issue.log (5,228 bytes) 2014-09-15 14:25
https://bugs.cacert.org/file_download.php?file_id=381&type=bug
EliminateExpired.pl (4,694 bytes) 2018-11-01 13:03
https://bugs.cacert.org/file_download.php?file_id=439&type=bug
EliminateExpired.V2.pl (7,889 bytes) 2018-11-01 13:03
https://bugs.cacert.org/file_download.php?file_id=440&type=bug
Notes
(0005594)
GuKKDevel   
2018-06-06 10:34   
At test.cacert.org is a first workaround available und /home/GuKKDevel/bug-1306/EliminateExpired.pl.

Since the CRL is built from the Database-file index.txt in the directory named in the configfile, above module reads this file and writes them either to the file for eliminated records or to the next index.txt-file, depending on date of revokation and expiration. both are to be younger than 62 days (2 months) in the past.

At this stage after that the files index.txt and index.temp.new have to be renamed manually.
(0005595)
egal   
2018-06-06 10:40   
There is a retention time of three months after the last certificate expired/was revoked before an account can be closed for support. I suggest the same duration for CRL.
(0005597)
GuKKDevel   
2018-06-06 10:57   
aggreed so lets make it 100 days
(0005634)
GuKKDevel   
2018-11-01 13:03   
I did a fix.

appended are two version to choose.
(0005791)
Ted   
2019-04-05 21:33   
Current signer configuration can be found at https://svn.cacert.org/CAcert/SystemAdministration/signer/
(0006064)
Ted   
2021-08-07 19:24   
Created branch bug-1306 (on github) and merged the pull request of @GuKKDevel into it


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1510 [Main CAcert Website] certificate issuing major always 2021-03-12 18:18 2021-08-07 08:36
Reporter: alkas Platform: Default  
Assigned To: OS: any  
Priority: normal OS Version: any  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions: see above
Summary: Browsers Basilisk and Palemoon are unable to produce a valid CSR, at least on Windows 10
Description: There were updates to the both named browsers yesterday (20210311). After that, no valid CSR could be produced for client certificates using Basilisk or Palemoon browser, under the Windows 10 OS (Insider last Build 21301, dated 20210123). The Seamonkey browser (with no updates) worked OK.
So I would like recommend to implement the CAcert web update proposal suggested in the problem 1502--5956 ASAP. There is possibility, that after Seamonkey browser will be next updated, it also will lost the ability to produce a valid CSR.
Tags: Basilisk, browsers, client certificate, issuing, Palemoon
Steps To Reproduce: Try to create a new client certificate using Palemoon or Basilisk browser. You will end with the well known error message "...use another browser."
Additional Information:
System Description Default profile.
Attached Files:
Notes
(0006058)
alkas   
2021-08-07 07:59   
Solved by browsers Authors.
(0006059)
Golffies   
2021-08-07 08:24   
Hi Ales, what do you mean?
(0006060)
alkas   
2021-08-07 08:36   
This item should be closed, as both browsers are already fixed.
What means they are able again to produce CSRs.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1534 [Main CAcert Website] certificate issuing major always 2021-07-21 13:59 2021-08-06 09:33
Reporter: alkas Platform: Main CAcert Website  
Assigned To: bdmc OS: N/A  
Priority: normal OS Version: stable  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: A proposal: submitting CSRs as files P10
Description: Utilites as Kleopatra produce CSRs n the P10 Binary format, other as the P10 Base64 format. The CAcert main web should accept such files and use a simple contents test with a simple conversion Binary --> Base64.
Tags: Base64, CSR, P10
Steps To Reproduce: To submit a file is impossible in present. If the file has Base64 format, you are able to copy and paste its CONTENT only.
Additional Information: Most questions to Support are just about the impossibility of browsers to make a CSR.
Make a CSR is complicated for a common user. Let's simplify that.
System Description Production version of the CAcert website
Attached Files:
Notes
(0006044)
Ted   
2021-08-05 18:39   
We'll probably need a button to upload the file, since currently the CSR is entered by Copy/Paste which does not work for binary files.

If someone can look up the OpenSSL command line to do the conversation, please add it as a note here.
(0006045)
alkas   
2021-08-05 19:30   
The following openSSL command will do that. I have tested it.

openssl req –in <your .p10 file> -inform der –out <a new file name>

and the new file name can have any extension (e.g. .csr)
(0006048)
Golffies   
2021-08-06 09:33   
The topic was discussed at the developer meeting on 5 August 2021.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1305 [Main CAcert Website] certificate issuing major always 2014-09-15 14:07 2021-08-05 17:49
Reporter: wytze Platform: Main CAcert Website  
Assigned To: Ted OS: N/A  
Priority: urgent OS Version: stable  
Status: needs review & testing Product Version: 2014 Q3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: dastrath, Ted
Test Instructions:
Summary: CAcert Class1 root certificate needs to be reissued with an updated CDP and a SHA-based signature
Description: The CAcert Class1 root certificate (THE CAcert root) is suffering from two operational problems:

1. The CDP (CRL Distribition Point) listed in the root cert is
        https://www.cacert.org/revoke.crl
But since we do not want to distribute the (huge) CRL through our main web server but rather through a specialized CRL server, the main web server is redirecting all requests for the above URL to http://crl.cacert.org. It turns out that some validation software, for example Microsoft's CryptoAPI, is unable to deal with such HTTP redirects, and reports a verification failure.

Also, the use of HTTPS in the CDP is *not* recommended, see RFC5280 http://tools.ietf.org/html/rfc5280, in the section Security Considerations:
   When certificates include a cRLDistributionPoints extension with an
   https URI or similar scheme, circular dependencies can be introduced.
   The relying party is forced to perform an additional path validation
   in order to obtain the CRL required to complete the initial path
   validation! Circular conditions can also be created with an https
   URI (or similar scheme) in the authorityInfoAccess or
   subjectInfoAccess extensions. At worst, this situation can create
   unresolvable dependencies.

So the CDP should be http://crl.cacert.org/revoke.crl.

2. The current root cert is signed with a MD5 hash. While from a security point of view, the quality of the hash algorithm used for such a trusted cert does not matter, from time to time rumours and sometimes even software appear which choke about this. A SHA-256 based signature would kill all such issues right away.

Tags: certificates
Steps To Reproduce: Issue 1 can be demonstrated with a command like this on a Windows 7 system:
     certutil -f -verify -urlfetch server.crt
for some CAcert Class3 issued server certificate. Output of the above command has been added as attachment to this bug entry.

Issue 2 is demonstrated somewhat by the currently open Bugzilla issue for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1058812
Additional Information: The CAcert Class3 intermediate root certificate has been resigned in 2011 to deal with the MD5 issue (for this cert, being intermediate, it was truly a blocking problem). A similar procedure could be used to resign the CAcert Class1 root. This will likely be a much faster process than waiting for the results of the NRE (New Roots & Escrow) project.
System Description Production version of the CAcert website
Attached Files: crl-redirect-issue.log (5,274 bytes) 2014-09-15 14:07
https://bugs.cacert.org/file_download.php?file_id=380&type=bug
Global Sign.p7b (936 bytes) 2014-10-04 09:58
https://bugs.cacert.org/file_download.php?file_id=384&type=bug
diff-release-bug-1305 (25,355 bytes) 2018-10-31 13:03
https://bugs.cacert.org/file_download.php?file_id=437&type=bug
diff (6,678 bytes) 2018-11-16 15:53
https://bugs.cacert.org/file_download.php?file_id=450&type=bug
CAcert_Root_Certificates_X0F_X0E.msi (1,593,344 bytes) 2018-11-16 15:53
https://bugs.cacert.org/file_download.php?file_id=451&type=bug
CAcert_chain_X0F_X0E.pem (7,503 bytes) 2018-11-18 00:43
https://bugs.cacert.org/file_download.php?file_id=452&type=bug
cacert-bundle_X0F_X0E.crt (16,180 bytes) 2018-11-18 00:43
https://bugs.cacert.org/file_download.php?file_id=453&type=bug
Poznámka 2018-12-03 223514.jpg (57,342 bytes) 2018-12-03 21:36
https://bugs.cacert.org/file_download.php?file_id=454&type=bug
CAcert_Root_Certificates_X0F_X0E.zip (354,216 bytes) 2018-12-14 12:30
https://bugs.cacert.org/file_download.php?file_id=457&type=bug
cap_X0F_X0E.docx (56,714 bytes) 2018-12-14 12:30
https://bugs.cacert.org/file_download.php?file_id=458&type=bug
cap-blank_X0F_X0E.docx (56,816 bytes) 2018-12-14 12:30
https://bugs.cacert.org/file_download.php?file_id=459&type=bug
cap_X0F_X0E.pdf (677,261 bytes) 2018-12-14 12:47
https://bugs.cacert.org/file_download.php?file_id=460&type=bug
cap-blank_X0F_X0E.pdf (602,157 bytes) 2018-12-14 12:47
https://bugs.cacert.org/file_download.php?file_id=461&type=bug
Notes
(0005486)
felixd   
2015-11-25 23:53   
There exists a procedure now that will fix this problem:
https://github.com/CAcertOrg/cacert-procedures/tree/master/rootResignSHA256

It was executed on test data on the FrosCON.
The following Audit report documents this execution:
https://wiki.cacert.org/Audit/Results/session2015.4

Currently the resulting files (re-singed test certificate, intermediate files, etc) are kept with Board that should soon release them to the public.

Therefore we should soon (after enough review) be good to go for the real certificate.
(0005492)
felixd   
2015-12-14 21:58   
We noticed problems related to keeping the serial of the Certificate. We therefore need to adjust the serial number to circumvent "reused issuer and serial"-errors when the Browser has both certificates (i.e. one installed and the other via the SSL Handshake)

I therefore propose:
https://github.com/yellowant/cacert-procedures/commit/a73faf1dbd8d88ebc490bd182db8c4c9e0dccaf2
(0005495)
cilap   
2016-02-05 09:50   
the issue has more pressure in the meanwhile.

On Java and Eclipse I am getting:
svn: E175002: SSL handshake failed: 'java.security.cert.CertificateException: Certificates does not conform to algorithm constraints'

Since oracle has enforced the default handling of rejecting MD2 and MD5 certificates, any SSL connection on Ubuntu 14.04 is failing in combination with a Java VM.
Sadly the implementation is so stupid, that all certificates are getting read in added to the trust store during first connection. And all certificates are checked, not only the once which should be checked on the chain from the server cert up to the root.

Is there any plan on reissuing the root certificate with a SHA fingerprint and to get rid of MD5withRSA

A workaround - but only working till next java update - is to change

vi /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security

and to change to this:

#jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

#jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768

But this is from security perspective not really nice, that CaCert is still working on his root cert on a "obsoleted" algorithm.

Hope I could help some guys with my report and the workaround description
(0005512)
reinhardm   
2016-03-14 17:00   
Today I added the new roots into the browser.
I am running OpenSUSE and firefox. The roots installed by a mouseckick with no problems. I tried several logins where certificate login is required. All woreked well.
I removed the old roots and made a login to https://bugs.cacert.org with no problems.
I will try further on different browsers and OS versions.
(0005542)
bjobjo   
2017-04-04 16:12   
Hello,
I increased the priority and severity.
Firefox is not accepting any more the Root Certificate, so we have to add an exception for every site that uses CA Cert Authority.

The ticket was opened in 2014 and we still don't have a new root cert.

The whole reputation of CAcert is in danger if the root certs are not secure.

Please do urgently fix this.
Current firefox message for example:

wiki.cacert.org uses an invalid security certificate. The certificate is not trusted because it was signed using a signature algorithm that was disabled because that algorithm is not secure. Error code: SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED
(0005586)
dops   
2018-04-18 21:37   
New signed roots are tested on multiple platforms, see here: https://lists.cacert.org/wws/arc/cacert-board/2018-04/msg00014.html
Some people reported to use the certificates for years without any problems.

Any person left in the software team is welcome to announce where people can continue working.
(0005628)
GuKKDevel   
2018-10-31 13:03   
a diff we started in Feb 2017 (Dirk, Aleš, and me)
(0005638)
Ted   
2018-11-01 22:53   
Golffies left a review at https://github.com/CAcertOrg/cacert-devel/pull/9#pullrequestreview-170861329
(0005660)
Ted   
2018-11-08 08:58   
Benedikt (who was internal Auditor in 2016) has confirmed that the following certificates are the correct ones:

Root:
Serial 0000015
finger print: 07ed bd82 4a49 88cf ef42 15da 20d4 8c2b 41d7 1529 d7c9 00f5 7092
6f27 7cc2 30c5
file:
http://svn.cacert.org/CAcert/SystemAdministration/signer/re-sign-2016/outputs/new1.txt

Class 3:
Serial 0000014
finger print: f687 3d70 d675 96c2 acba 3440 1e69 738b 5270 1dd6 ab06 b497 49bc
5515 0936 d544
file:
http://svn.cacert.org/CAcert/SystemAdministration/signer/re-sign-2016/outputs/new3.text
(0005663)
Ted   
2018-11-12 10:06   
Benedikt also confirms that from his Point of View the incident during the re-signing ceremony had no influence on the "trustworthyness" of the keys/certificates.

So, even if there were an Arbitration case about the details of the re-signing ceremony (I did not find one yet), I don't see any reason why the re-signed certificates should not be installed.
(0005665)
Ted   
2018-11-12 22:04   
As part of the review process I checked the differences between the "old" and the "new" root certificates:

1. Serial number: Old 0x0, New 0xf
2. Signature Algorithm: Old md5WithRSAEncryption, New: sha256WithRSAEncryption
3. X509v3 Authority Key Identifier: Old contains keyid, DirName and serial, New contains only keyid
4. X509v3 CRL Distribution Points: Old URI:https://www.cacert.org/revoke.crl, New URI:http://crl.cacert.org/revoke.crl
5. Netscape CA Revocation Url: Old https://www.cacert.org/revoke.crl, New URI:http://crl.cacert.org/revoke.crl
6. Authority Information Access: Old (not present), New OCSP - URI:http://ocsp.cacert.org
7. The signature obviously differs

Since there is no specification document about the intention of these changes I can only check for harmful side effects and guess about the intentions.

2. and 7. are obviously intended, these are direct concequences of using a different signing alhorithm

1. Is a side effect of re-signing. Since RFC5280 requires that "[The serial number] MUST be unique for each certificate issued by a given CA" the serial number cannot be the same as in the old certificate. The exact value of the new serial number is not critical, as long as it remains unique.

4., 5. and 6. have probably been adjusted to the value which is included in currently issued "normal" certificates. Using http over https to retrieve the CRL makes more sense since the crl itself is signed.

I'm not sure about 3. https://tools.ietf.org/html/rfc5280#section-5.2.1 does not address using the issuer DN in the X509v3 Authority Key Identifier. Current versions of OpenSSL add it only "if the keyid option fails or is not included" (https://www.openssl.org/docs/man1.0.2/apps/x509v3_config.html), which is obviously not the case here.
So I guess the issuer DN in Authority Key Identifier is just not used anymore in current software.
(0005666)
Ted   
2018-11-13 22:54   
Wytze has provided a pointer to https://github.com/BenBE/cacert-procedures/blob/root-resign-sha256/rootResignSHA256/procedure.txt

While it does not explain the reasons, it makes clear that the observed changes are intentional.

An additional mail provided by Wytze plausibly explains the reasons of removing issuer and serial from X509v3 Authority Key Identifier. Specifically the serial number must be removed (or adjusted), since the new roots will have different serial numbers, so the serial in Authority Key Identifier would otherwise break the certificate chain.
(0005673)
alkas   
2018-11-15 19:21   
The difference between CAcert Class 3 Root #A418A and CAcert Class 3 Root #0E

Serial number A418A 0E
Signature 29:28:85:ae:44:a9:b9:af:a4... 5a:90:16:d0:36:23:56:64:95...
X509v3 Extensions:
 X509v3 Authority Key Identifier:
  keyid:16:B5:32:1B:D4:C7:F3:E0:E6:8E:F3:BD:D2:B0:3A:EE:B2:39:18:D1 keyid:16:B5:32:1B:D4:C7:F3:E0:E6:8E:F3:BD:D2:B0:3A:EE:B2:39:18:D1
  DirName:/O=Root CA ---
          /OU=http://www.cacert.org
          /CN=CA Cert Signing Authority
          /emailAddress=support@cacert.org
  serial:00

Thus, only #A418A contains the serial number of CAcert Class 1 root # 00.
If the Class 3 Root #0E is used, there is only the http link in the following attribute (identical in both Class 3 roots):
X509v3 Basic Constraints: critical
                CA:TRUE
            Authority Information Access:
                OCSP - URI:http://ocsp.CAcert.org/
                CA Issuers - URI:http://www.CAcert.org/ca.crt
(where the file ca.crt contains the Class 1 Root #00)

Now, if the Class 3 Root #0E is used, and the file ca.crt is replaced by Class 1 Root #0F (SHA256 signed),
the Class 3 Root is no more tied with the specific (#00) Class 1 Root.
I have tried this certificate chain on my local network with 2 Web servers, no problems.
The chain is: CAcert Class 1 Root #0F +--> CAcert Class 3 Root #0E --> any certificate issued by Class 3 Root
                                                                  +--> any certificate issued by Class 1 Root
Issued client/server certificates do not contain any serial # of signing root(s).

Do anybody knows any objections against this concept?
(0005675)
Ted   
2018-11-15 20:23   
Hi alkas,

you are completely right, and were just a little bit faster than me in documenting this facts. :-)

As I found out while digging through the documentation, this issue has already been noticed during the tests in 2016, it just was not documented here in the bugtracker, but in some external documents.

Since the issue has been tested in 2016, and the whole thing is quite plausible, once someone explains it to you :-), I don't consider it essential to redo all the tests.

Of course you are nevertheless welcome to replicate the tests and report the results here. But IMHO this is not blocking the continuation of the review.
(0005677)
Ted   
2018-11-15 22:14   
(Last edited: 2018-11-15 22:14)
I had a look at the code changes in the bug-1305 branch from GitHub, and I'd propose a few changes:

* Remove the Windows Installer file CAcert_Root_Certificates_256.msi and the section referring to it. See my mail to the development list for detailed reasons.
* Remove the sections of the "old versions". The history of the root keys is documented in the WiKi page https://wiki.cacert.org/Roots/StateOverview

Of course the WiKi page has to be updated once we roll out bug-1305.

(0005680)
GuKKDevel   
2018-11-16 15:53   
certificates were renamed to correspond to their version, new .msi-installer was added, page to download (pages/index/3.php) was changed to access the new certificates
(0005683)
alkas   
2018-11-18 00:43   
Two more formats:
(0005686)
Ted   
2018-11-19 22:54   
GuKKDevel: The fingerprints in the CAP and COAP forms have to be adjusted to the new root certs. See www/cap* and www/coap*

I'd propose to add a "(since 2019)" text beside the fingerprints, so people may get the idea that the change was intentional...

If you want to discuss this drop a message to the development list.
(0005687)
Ted   
2018-11-23 20:59   
Mental note: The updated certificates have to be installed on the signer machine also!
(0005688)
wytze   
2018-11-24 08:22   
With respect to note https://bugs.cacert.org/view.php?id=1305#c5687 :
I agree that for consistency the updated root certificates should also be installed on the signer machine, but please note that for the operation of the signer this does not make any difference. The certificates issued by the signer only depend on the ssl configuration files and the root private key; the root certificate has no influence on this. The practical consequence of this is that installation of the updated root certificates can be postponed (or advanced) to a convenient moment (i.e. the need for other maintenance on the signing server), and does not have to be coordinated with the publication/installation of the updated roots on the webdb server.
(0005690)
Ted   
2018-11-28 11:21   
GuKK: I merged your changes (only the cap*/coap*-Files) into the test-1260 branch which is installed on the testserver.

Now you can open the CAP forms in the testserver, and you'll see the next problem: The SHA256 checksums are considerably longer than the old MD5 ones.

So we'll probably need them on two lines. But then we have to make sure that the resulting form still fits one A4 / Letter page (at least when using the english form)... So, probably, you'll have to dig around a bit more... :-(
(0005691)
GuKKDevel   
2018-11-30 13:16   
worked on cap.php
split fingerprint line into two
form fits to A4 and letter

all other cap*/coap*-files: couldn find a link to them so waiting for answer from Wytze, who designed them.
(0005692)
wytze   
2018-12-02 08:10   
There appears to be a serious misunderstanding here ... I am *not* the author or designer of the cap/coap files. Inside for example capnew.php you can find a statement about the origin of these files:

/*
** Created from old cap.php 2003, which used the now obsoleted ftpdf package
** First created: 12 July 2008
** Last change: see Revision date
** Reviews:
** printed text by Ian Grigg and Teus Hagen (July 2008)
** layout/design by Teus Hagen and Johan Vromans (July 2008)
** coding by Teus Hagen and ...

Teus Hagen, former president of CAcert Inc. is the main author as far as I remember, but he is not involved anymore with CAcert. These files were meant as a replacement for the old forms, which are based on software which was already obsolete in 2008, and even more so in 2018. But nobody in software was ever prepared to spend some time to switch over to the new versions. So they are in the source tree, but not actually used.

There is no urgent need to update these files. If someone ever decides to switch over to them, adjusting the fingerprint text will be a minor effort.

By the way, I am kind of surprised that the fingerprint layout issue has been raised. There is no real need to display SHA256 fingerprints rather than SHA1 fingerprints for the new roots, the hash algo for the fingerprint does not need to match the hash algo of the certificate's signature (note that currently they also don't match: MD5 vs SHA1). Just updating the SHA1 fingerprints would have been fine I think.
(0005693)
Ted   
2018-12-03 20:25   
Hmm, I checked what I had in easy reach to find out which kind of fingerprint/checksum is shown by different software:
Windows 7: SHA1
Windows 10: SHA256
Firefox: SHA1 & SHA256

So, I guess it's OK to move to SHA256 only fingerprints on the CAP forms...
(0005694)
Ted   
2018-12-03 20:36   
GuKK: The PDF in letter format is quite full now... Is it easy to reduce the space above the upper box a bit (maybe half), so there's a bit of reserve at the bottom? Some translations need nore room than the english document...

And, when looking at the german PDF I noticed that at least the CCA agreement term is set in block, which does not look very nice here. It has probably been so forever, but, as above, if it is not much work please change this to ragged margin ("Flattersatz") while we are at it.

Once more, both of these are nice to have. I'd prefer to get the certs online without these changes in December to getting them online with the changes in January...
(0005695)
jandd   
2018-12-03 20:40   
openssl 1.1.0g x509 -fingerprint: SHA1
JDK 8 keytool -printcert: SHA1 & SHA256
gnutls 3.5.18 certtool --fingerprint: SHA1

I suggest to put both SHA1 and SHA256 fingerprints on the CAP forms
(0005698)
alkas   
2018-12-03 21:36   
AFAIK, Windows 10 shows SHA1 fingerprint, too - in system cert. viewer - mmc, module Certificates, select and open cert., view Details, at the end is Fingerprint.
(0005699)
GuKKDevel   
2018-12-07 12:27   
Ted: It is designed explicitely to place the two boxes "Applicant's Statement" and "CAcert Assurer" at exact the positions where they are, we shouldn't change that.

The other point: if we make this line two for all languages there is no problem. else I need to find out how to mask a space/blank or we have to change the pootle-files for appening a space to one literal.
I tried some versions a whole day. (I think we should not implement this for the moment)
(0005700)
Ted   
2018-12-07 22:48   
As decided on today's meeting (https://wiki.cacert.org/Software/Meeting/20181207) we want to add SHA1 fingerprints.

The rest of the formatting issues is considered low priority.
(0005701)
GuKKDevel   
2018-12-10 13:13   
ted: fingerprints asre at the CAP-form. please check and if correct add to testserver.

https://github.com/CAcertOrg/cacert-devel/pull/19/commits/ca4e5f03eef4a8a174437fb065a967ce92dab847
(0005702)
Ted   
2018-12-12 19:38   
Current changes are installed on the testserver in branch test-1442.

I checked the german and the english PDF, both are OK, the SHA1 fingerprints match with what I get shown on Windows 7.

Now we need at least two test reports of other people (not the developer and the reviewers), so please test the CAP forms on https://test.cacert.org/index.php and leave reports!
(0005703)
bdmc   
2018-12-13 15:28   
Where do I find documented the appropriate fingerprints for the SHA-256 Root and Class 3 certificates? I would expect them to be noted in this "Bug" documentation, perhaps in the "Instructions for Testers," so that testers could confirm the values found on forms and other places.
(0005704)
bdmc   
2018-12-13 15:29   
I see on the US-English CAP Form that the address is "Oatley." Is this correct?
(0005705)
bdmc   
2018-12-13 15:31   
I see the following values on the CAP PDF.

SHA256: root: 07ED BD82 4A49 88CF EF42 15DA 20D4 8C2B 41D7 1529 D7C9 00F5 7092 6F27 7CC2 30C5
and class3: F687 3D70 D675 96C2 ACBA 3440 1E69 738B 5270 1DD6 AB06 B497 49BC 5515 0936 D544
(0005706)
kronenpj   
2018-12-13 21:57   
The SHA1 and SHA256 checksums are correctly represented in the CAP files, based on the certificates attached as https://bugs.cacert.org/file_download.php?file_id=452&type=bug and https://bugs.cacert.org/file_download.php?file_id=453&type=bug. I did not check the .msi file.
(0005707)
L10N   
2018-12-13 22:03   
I found this overview on the wiki:
https://wiki.cacert.org/Roots/StateOverview
(0005708)
L10N   
2018-12-13 22:59   
No, Oatley is outdated. The current address is:
Hangar 10 Airfield Avenue, Murwillumbah NSW 2484, New South Wales, (Commonwealth of) Australia
(0005709)
GuKKDevel   
2018-12-14 11:39   
Changed the address of CAcert Inc. and changed the sha1-fingerprints presentation from 2-char plus colons to 4-chars plus space.
(0005710)
alkas   
2018-12-14 12:30   
The new version of CAcert root certificates (zipped) and Czech new versions of CAPs. Please have a look.
(0005711)
alkas   
2018-12-14 12:47   
PDF versions:
(0005712)
L10N   
2018-12-14 13:11   
I tested CAcert_Root_Certificates_X0F_X0E.zip
- on Windows 10 Pro, version 1803: unzip, start, there was a warning with a button to abort, i clicked on more information to see another button to proceed anyay, what I did. The I uninstalled the root certs. It finished with an error message :"Error." and two buttons: Yes, No. I clicked on Yes, closed the installer.
I restarted the installer. As there were no more CAcert roots certs installed, a window asked me to accept the root distribution license. I did, installation was successfull.

- on Windows 7 Starter 6.1 version 7601: Start the installer, security warning, accept licencese, install process with an window telling me information about the cert beeing installed. clicked OK. installation was successfull
(0005713)
L10N   
2018-12-14 14:39   
Aleš wrote (by mail): "It’s better to install the roots as anybody with the Administrator’s rights, The Yes-No dialog then will not appear, I guess."

As I have no admin rights on my emplyers PC, I cannot re-test it this way.
(0005715)
Ted   
2018-12-16 21:40   
New changes are installed on the testserver: Corrected CAcert postal address and format of fingerprints in the CAP forms
(0005738)
bdmc   
2019-01-18 21:13   
Just examined the test server, and the current version appears correct.

The certificate SHA-256 fingerprints on Page 3, and all four CAP forms, agree in format and content.

The certificate downloaded also appears correct, with the correct serial number and SHA256.

The four CAP forms have the correct mailing address.
(0005740)
alkas   
2019-01-21 16:08   
The Wiki pages /CapHTML and /CoapHTML contain both old signatures and CAcert's "classical post" address in Australia.
(0005741)
L10N   
2019-01-21 22:16   
The Wiki page /CapHTML is updated as follows:
- old Oatley postal address replaced by Murwillumbah address
- new sha256 signed fingerprints added (old ones remaining, as form is allready online, to be removed after certificate roll out)

The Wiki page /CoapHTML is updated as follows:
- very old Denistone East postal address replaced by Murwillumbah address
- new sha256 signed fingerprints added (old ones remaining, as form is allready online, to be removed after certificate roll out)

Finterprints added to both forms:
class 1: DDFC DA54 1E75 77AD DCA8 7E88 27A9 8A50 6032 52A5
class 3: A7C4 8FBE 6B02 6DBD 0EC1 B465 B88D D813 EE1D EFA0
(0005770)
Ted   
2019-02-14 20:43   
merged updated release branch into bug-1305
(0005771)
Ted   
2019-02-14 21:23   
(Last edited: 2019-02-14 21:24)
Karl-Heinz, can you add the SHA1-fingerprints to pages/index/3.php and set CAcert's correct postal address in
www/cap.html.php
www/capnew.php
www/coap.html.php
www/coapnew.php

Though I don't know exactly when these pages are used, we should not have documents with the outdated postal address on the main server.

The c(o)ap* files also miss the SHA1 fingerprint. I'd propose to add them while you are already at it. But that's less important at the moment, if problems (for example with formatting) should occur please just add a note here and concentrate on more important things.

(0005780)
bdmc   
2019-03-08 01:24   
I have updated the address in all of the above four files.

However, they also appear to contain the SHA1 fingerprints already. Perhaps someone else did that.
(0005781)
Ted   
2019-03-12 22:51   
Changes are merged into test-1442 branch and installed on https://test.cacert.org
(0005782)
Ted   
2019-03-17 22:28   
Brian, in pages/index/3.php the sha1 checksum is still missing. Can you add it?
(0005783)
bdmc   
2019-03-19 18:23   
Done and checked in.
(0005784)
Ted   
2019-03-31 13:31   
(Last edited: 2019-03-31 13:37)
Brian pointed me to the GPG signed message on the key download page (pages/index/3.php), which still uses the old fingerprints.

Since at the moment I don't know who may create a new message of this kind (access to the signer machine would probably be needed!) I asked Brian to remove the message from the page.
If we find a way to create a GPG message with the new fingerprints (now or later) it would make sense to add it once more.

The second GPG message is, more or less, a "self signature of the GPG key". While IMHO this is not really useful, does not hurt, so I'd keep it.

(0005785)
bdmc   
2019-03-31 14:33   
In one of my versions of my "fix," I had removed that heading, but in the final one I had put it back.

It is now moved to within the "commented out section," and a comment has been added, trying to explain what we did.

All checked in.
(0005786)
Ted   
2019-03-31 15:07   
Great! I'll have a look at it during the next hours...
(0005787)
Ted   
2019-03-31 18:37   
Reviewed commit da4c71a246b80f399f3a12823ac03fa8c40f42bb versus current release commit 8ab79aad9fd3685129060854340dccd5dbf01a1d

Though some formatting problems remain, especially in www/capnew.php the review is PASSED
(0005788)
wytze   
2019-04-01 12:46   
With respect to https://bugs.cacert.org/view.php?id=1305#c5784:

The procedure for generating these GPG signatures is documented in https://bugs.cacert.org/view.php?id=1254

The script mentioned there was left on the signer after its execution on Nov 11, 2014, and could be run again after installing re-signed certs on the signer. Obviously this does require visit to the signer machine by two critical system administrators and one access engineer.
(0005790)
egal   
2019-04-05 20:39   
There are some format issues (especiall in www/capnew.php), but as this CAP-form is (normally) not in use, the review is PASSED.

PGP/GnuPG-signatures are currently commented out, but can be added at a later time (as this requires a visit of the signer, can be done together with another bug).
(0005792)
Ted   
2019-04-07 12:43   
Sent patch request to critical team, but without CAcert_Root_Certificates_X0F_X0E.msi, since I don't know how I should review that...
(0005793)
wytze   
2019-04-10 10:19   
The patches have been installed on the production server on April 10, 2019, including the re-signed root certifcates.
See also the log message sent to the cacert-systemlog mailing list here: https://lists.cacert.org/wws/arc/cacert-systemlog/2019-04/msg00002.html
(0005794)
wytze   
2019-04-10 10:21   
See note https://bugs.cacert.org/view.php?id=1305#c5793
(0005795)
wytze   
2019-04-10 10:30   
One thing to note: since the patch has added the re-signed root certificates with new names to the system and left the old root certificates in place under their original names, it is still possible that users and applications retrieve the old root certificates. And observing the Apache2 access log, this is indeed the case -- clearly there are some applications which have
these names/paths built-in. They will not benefit from this patch.
To tackle this problem, one could consider to change the old certificates to copies of their new counterparts, so users and applications will retrieve the new version irrespective of the name/path used.
(0005796)
Ted   
2019-04-10 18:54   
According to Wytze's note I re-open this case to create a follup-up patch.
(0005797)
Ted   
2019-04-10 19:03   
(Last edited: 2019-04-10 19:04)
Probably the easiest solution will be to rename the old certificate files to something else (like root_X00.* and class3_XA418A.*) and copy the new files to the old names also. So in the future we'll use root.* and class3.* for the "current" certificates, and in addition make the whole history of certificates available using the names with attached serial numbers.

(0005798)
bdmc   
2019-04-11 00:05   
As discussed above, I have renamed the old certificate files to include their Serial Numbers in the file name.

I have also copied the current, latest, certificate files to "root.crt" and "class3.crt" to allow for systems that do not properly follow the URI.
(0005799)
bdmc   
2019-04-11 00:06   
Changed and checked in as per your notes.
(0005800)
alkas   
2019-04-11 17:27   
I have CAcert to issue a new certificate yesterday evening. I have received the following E-mail then, containing two fingerprints of CAcert root(s?).
The first fingerprint belongs to unknown certificate, and the second fingerprint belongs to the old Class 1 root.
I guess that should be corrected.
----
Hi Aleš,

You can collect your certificate for alkas@volny.cz by going to the following location:

https://www.cacert.org/account.php?id=6&cert=645849

If you have not imported CAcert's root certificate, please go to:
https://www.cacert.org/index.php?id=3
Root cert fingerprint = A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B
Root cert fingerprint = 135C EC36 F49C B8E9 3B1A B270 CD80 8846 76CE 8F33

Best regards
CAcert.org Support!
(0005801)
wytze   
2019-04-12 08:57   
With respect to https://bugs.cacert.org/view.php?id=1305#c5800 :
- the first fingerprint shown is the MD5 fingerprint of the "old" root certificate
- the second fingerprint shown is the SHA1 fingerprint of the "old" root certificate
- clearly these messages should be replaced by:
  SHA256 fingerprint: 07ED BD82 4A49 88CF EF42 15DA 20D4 8C2B 41D7 1529 D7C9 00F5 7092 6F27 7CC2 30C5
  SHA1 fingerprint: DDFC DA54 1E75 77AD DCA8 7E88 27A9 8A50 6032 52A5
- the affected source file is CommModule/client.pl
(0005802)
bdmc   
2019-04-12 16:16   
client.pl has been corrected and checked in.
(0005803)
Ted   
2019-04-15 19:52   
(Last edited: 2019-04-15 19:53)
A grep for the old fingerprints returns more hits in files www/ttp.php, pages/index/3.php and pages/index/16.php. 3.php and 16.php include the fingerprint also in a PGP signed message, which should be commented out completely...

(0005804)
bdmc   
2019-04-26 14:08   
There is a reference in 16.php to 17.php, which is intended to install the Microsoft Certificate.

Should this be removed?
(0005805)
bdmc   
2019-04-26 14:25   
Files ttp.php and 16.php have been corrected and checked in.

The reference found in 3.php is inside the commented out message about the GPG signature.
(0005809)
Ted   
2019-05-14 20:17   
The fixes of bug-1305 branch have been merged into the (old) testserver. Please try and check if the reported problems of wytze and alkas (and myself) are fixed, and report here!
(0005810)
alkas   
2019-05-25 21:03   
There are the old fingerprints in letters as this:
--------------------------------------
Hi <user>,

You can collect your certificate for <user-email> by going to the following location:

https://www.cacert.org/account.php?id=15&cert=797035

If you have not imported CAcert's root certificate, please go to:
https://www.cacert.org/index.php?id=3
Root cert fingerprint = A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B
Root cert fingerprint = 135C EC36 F49C B8E9 3B1A B270 CD80 8846 76CE 8F33

Best regards
CAcert.org Support!
(0005811)
L10N   
2019-05-26 18:18   
Where is the text of this e-mail stored?
(0005812)
GuKKDevel   
2019-05-27 08:29   
Message comes from -> CommModule/client.pl
(0005813)
GuKKDevel   
2019-05-27 08:55   
should be correct see https://github.com/CAcertOrg/cacert-devel/blob/bug-1305/CommModule/client.pl
(0005814)
bdmc   
2019-05-31 04:40   
client.pl should have been corrected in the April 12th check-in.
(0005815)
Ted   
2019-07-04 23:05   
After some hassle, the (old) testserver is now running the modified client.pl

I created one certificate, and the mail (on mgr.test.cacert.org:14843) contained the new checksums. It looked acceptable, though not really nice...

Any other test reports?
(0005845)
Ted   
2019-09-26 18:28   
I updated https://wiki.cacert.org/Roots/StateOverview to match the current status...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1532 [Main CAcert Website] certificate issuing major always 2021-07-13 21:11 2021-07-13 21:11
Reporter: alkas Platform: Default  
Assigned To: OS: any  
Priority: normal OS Version: any  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions: see above
Summary: DNSSEC _sha256.class3_x14E228.g1._fp.cacert.org. and _url.class3_x14E228.g1._fp.cacert.org. do not exist
Description: CAcert's DNSSEC does not contain data of the new Class3 root yet. The info of the old Class 3 root is still active there. Thus, a check is impossible for the new Class 3 Root.
Tags: Class 3 Root, DNSSEC
Steps To Reproduce: nslookup
set type=txt
_sha256.class3_x14E228.g1._fp.cacert.org. -or- _url.class3_x14E228.g1._fp.cacert.org.
 - no result -
_sha256.class3_X0E.g1._fp.cacert.org. -or- _url.class3_x0E.g1._fp.cacert.org.
 - works -
Additional Information:
System Description Default profile.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1531 [test.cacert.org] test.cacert.org feature always 2021-06-27 19:05 2021-06-27 19:57
Reporter: tim.devries Platform: Default  
Assigned To: tim.devries OS: any  
Priority: none OS Version: any  
Status: solved? Product Version:  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: login continually fails. certificates are not signed and user engagement is very low.
Description: As above
Tags:
Steps To Reproduce: attempt login with valid certificate and email/password.

Check tecreations.ca. You should be able to fork from that.

Additional Information: You may want to checkout https://tecreations.ca/downloads/java/release/signed-cacert.org.jar. It is signed with my current CACert.org certificate. I can transition and replicate CACerts' functionality, however there isn't much point to that. Perhaps the people are saying they don't require security, given privacy laws and what not.
System Description Default profile.
Attached Files:
Notes
(0006034)
Ted   
2021-06-27 19:55   
Do I get this right, you want to log in to https://test.cacert.org/, with your "normal" password and/or certificate which work for https://www.cacert.org?

This is indeed as designed. Accounts from www.cacert.org are not valid for the testserver.

Please have a look at https://wiki.cacert.org/Software/Assessment/TestserverManagementSystem#Instructions_for_the_beginning (and the rest of the page) on a description how to create an account for the testserver.
(0006035)
Ted   
2021-06-27 19:57   
BTW, https://tecreations.ca/downloads/java/release/signed-cacert.org.jar leads to a "page not found" for me. How is this related to the login on the testsystem?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1530 [Main CAcert Website] GPG/PGP minor always 2021-06-20 17:17 2021-06-21 18:09
Reporter: jandd Platform: Main CAcert Website  
Assigned To: egal OS: N/A  
Priority: normal OS Version: stable  
Status: needs review & testing Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: inconsistent retry behaviour for empty/missing/broken gpg signatures
Description: The signer client handles incomplete/missing gpg signatures differently than X.509 certificates. The database table already has a warning column (tinyint) that is initialized with 0. For X.509 certificates this field is incremented for every failed signing attempt. For OpenPGP this is not the case. They are retried without an abort condition.
Tags:
Steps To Reproduce: Have a signer failure or write some garbage in the CSR file on the webdb system. See the failed gpg signing attempt on every signer loop run (in HandleGPG of CommModule/client.pl).
Additional Information: We have > 100 such failing gpg requests in the production system but none in the test system.
System Description Production version of the CAcert website
Attached Files: 1530_Implement_warning_thresholds_for_OpenPGP.patch (1,991 bytes) 2021-06-20 17:24
https://bugs.cacert.org/file_download.php?file_id=504&type=bug
Notes
(0006015)
jandd   
2021-06-20 17:24   
The attached patch implements the OpenPGP variant of the warning threshold and allows consistent configuration of the threshold for X.509 and OpenPGP.
(0006016)
bdmc   
2021-06-21 18:09   
This solution appears reasonable, and should correct the issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1449 [Main CAcert Website] source code feature always 2018-11-11 19:02 2021-05-31 12:27
Reporter: bdmc Platform:  
Assigned To: bdmc OS:  
Priority: high OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Move configuration from code to external file
Description: Extract items that control operation of CAcert web site from source code into a file external to the web site.

As Peter M. suggested, I am creating a file to contain a set of PHP define statements. These defines will allow changes to the operation of the web site.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0005667)
bdmc   
2018-11-14 03:40   
Here is a crude implementation of a configuration file. It should be named "config.php" and placed in the directory above "www" in the CAcert web site source tree.

<?php
/*
    LibreSSL - CAcert web application
    Copyright (C) 2004-2018 CAcert Inc.

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; version 2 of the License.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/

define("PROD_STATE", "prod");

define['MCONN_HOST', "127.0.0.1");
define['MCONN_USER', "username");
define['MCONN_PASS', "password");

define('NORMALHOSTNAME', "www.cacert.org" );
define('SECUREHOSTNAME', "secure.cacert.org" );
define('TVERIFY', "tverify.cacert.org" );

define('TEST_EMAIL_TO', "brianmccullough@cacert.org");
(0005668)
GuKKDevel   
2018-11-14 14:02   
I don't think, this bug blocks bug 1260
(0005672)
bdmc   
2018-11-14 17:59   
I'm sorry. I don't understand. This bug is a child of bug 1260, and is intended to contribute to its correction.
(0005676)
Ted   
2018-11-15 20:39   
I agree GuKK that this issue is a nice-to have.
It is not needed for the migration to the new PHP version, in fact, it is quite independent from it.

Seperating code from configuration information is preferred from a theoretical (or call it "aestethic") point of view, but the code as it is now will not pose any problems on PHP 7, or am I overlooking something?

IMHO your proposal also does not really improve the situation, since it is still implemented as a PHP file, which may be looked on as "code". If I understood Jan correctly, he'd prefer to have a plain text file to hold configuration information, like an *.INI file used on windows. And this is how I also think about this topic.

So I'd propose to remove the dependency on 0001260, and maybe lower the priority of this issue.
(0005679)
bdmc   
2018-11-15 23:58   
The solution shown here was intended as an interim change that was only part way toward the "correct" solution. It is expected to be replaced with an INI-file solution, but is a way to begin to remove sensitive information from the regular source tree. The config.php file was not expected to be added to the source code stored in the repository.
(0005722)
bdmc   
2019-01-02 06:16   
I have created a VM for myself to allow me to test code, in particular this, and have made progress with a proper Config class. More news to come.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1260 [Main CAcert Website] source code block always 2014-03-19 10:39 2021-05-31 12:27
Reporter: BenBE Platform:  
Assigned To: BenBE OS:  
Priority: urgent OS Version:  
Status: needs work Product Version: 2014 Q1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2014 Q2  
Reviewed by:
Test Instructions:
Summary: Make the source compatible with recent PHP versions
Description: Make the source run at least with PHP 5.5 or more recent
Tags:
Steps To Reproduce:
Additional Information: Current source presented by General Failure.
Attached Files:
Notes
(0004872)
wytze   
2014-06-26 14:36   
Just some samples of running against PHP 5.4 from Debian Wheezy:

HP Deprecated: mysql_escape_string(): This function is deprecated; use mysql_real_escape_string() instead. in /www/includes/lib/general.php on line 35, referer: https://cacert2.it-sls.de/index.php
PHP Deprecated: mysql_escape_string(): This function is deprecated; use mysql_real_escape_string() instead. in /www/includes/lib/general.php on line 37, referer: https://cacert2.it-sls.de/index.php
PHP Deprecated: mysql_escape_string(): This function is deprecated; use mysql_real_escape_string() instead. in /www/www/index.php on line 254, referer: https://cacert2.it-sls.de/index.php?id=4
PHP Deprecated: mysql_escape_string(): This function is deprecated; use mysql_real_escape_string() instead. in /www/www/index.php on line 255, referer: https://cacert2.it-sls.de/index.php?id=4
PHP Deprecated: mysql_escape_string(): This function is deprecated; use mysql_real_escape_string() instead. in /www/www/verify.php on line 104
PHP Notice: Undefined index: oldlocation in /www/www/index.php on line 336, referer: https://cacert2.it-sls.de/index.php?id=4

Even with PHP 5,3 on Debian Squeeze, there are already quite some warnings generated:

PHP Deprecated: Function ereg() is deprecated in /www/www/gpg.php on line 461, referer: https://secure.cacert.org/gpg.php?id=0
PHP Deprecated: Function ereg() is deprecated in /www/www/gpg.php on line 465, referer: https://secure.cacert.org/gpg.php?id=0
PHP Deprecated: Function ereg() is deprecated in /www/www/gpg.php on line 483, referer: https://secure.cacert.org/gpg.php?id=0
PHP Fatal error: Call to undefined function GetY() in /www/www/capnew.php on line 1011
PHP Fatal error: Call to undefined function GetY() in /www/www/capnew.php on line 1011, referer: http://wiki.cacert.org/Assurance/CustomizedCAP/DE
PHP Fatal error: Call to undefined method CAPPDF::AddSJISFont() in /www/www/capnew.php on line 1603
PHP Warning: checkDebianVulnerability(): /usr/share/openssl-blacklist/blacklist.RSA-16384 is not readable. Unsupported key size? in /www/includes/lib/check_weak_key.php on line 335, referer: https://www.cacert.org/account.php
PHP Warning: checkDebianVulnerability(): /usr/share/openssl-blacklist/blacklist.RSA-2432 is not readable. Unsupported key size? in /www/includes/lib/check_weak_key.php on line 335, referer: https://www.cacert.org/account.php
PHP Warning: checkDebianVulnerability(): /usr/share/openssl-blacklist/blacklist.RSA-3072 is not readable. Unsupported key size? in /www/includes/lib/check_weak_key.php on line 335, referer: https://secure.cacert.org/account.php
PHP Warning: checkDebianVulnerability(): /usr/share/openssl-blacklist/blacklist.RSA-3096 is not readable. Unsupported key size? in /www/includes/lib/check_weak_key.php on line 335, referer: https://secure.cacert.org/account.php
PHP Warning: checkDebianVulnerability(): /usr/share/openssl-blacklist/blacklist.RSA-5024 is not readable. Unsupported key size? in /www/includes/lib/check_weak_key.php on line 335, referer: https://www.cacert.org/account.php
PHP Warning: checkDebianVulnerability(): /usr/share/openssl-blacklist/blacklist.RSA-8092 is not readable. Unsupported key size? in /www/includes/lib/check_weak_key.php on line 335, referer: https://secure.cacert.org/account.php?id=10
PHP Warning: checkDebianVulnerability(): /usr/share/openssl-blacklist/blacklist.RSA-8192 is not readable. Unsupported key size? in /www/includes/lib/check_weak_key.php on line 335, referer: https://www.cacert.org/account.php?id=5
PHP Warning: DOMDocument::load(): CData section not finished\n

<code>German version below</code>

\n

There in /www/pages/index/feed.rss, line: 350 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): CData section not finished\n

[Translations Dutch, German and Spanish see bel in /www/pages/index/feed.rss, line: 89 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Document is empty in /www/pages/index/feed.rss, line: 1 in /www/pages/index/0.php on line 41, referer: https://secure.cacert.org/account.php?id=5
PHP Warning: DOMDocument::load(): Premature end of data in tag channel line 11 in /www/pages/index/feed.rss, line: 197 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Premature end of data in tag creator line 197 in /www/pages/index/feed.rss, line: 197 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Premature end of data in tag encoded line 231 in /www/pages/index/feed.rss, line: 350 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Premature end of data in tag encoded line 73 in /www/pages/index/feed.rss, line: 89 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Premature end of data in tag item line 192 in /www/pages/index/feed.rss, line: 197 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Premature end of data in tag item line 212 in /www/pages/index/feed.rss, line: 350 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Premature end of data in tag item line 58 in /www/pages/index/feed.rss, line: 89 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Premature end of data in tag rss line 2 in /www/pages/index/feed.rss, line: 197 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Premature end of data in tag rss line 2 in /www/pages/index/feed.rss, line: 350 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Premature end of data in tag rss line 2 in /www/pages/index/feed.rss, line: 89 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Start tag expected, '<' not found in /www/pages/index/feed.rss, line: 1 in /www/pages/index/0.php on line 41
PHP Warning: DOMDocument::load(): Unregistered error message in /www/pages/index/feed.rss, line: 197 in /www/pages/index/0.php on line 41
PHP Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /www/includes/general.php on line 82, referer: https://secure.cacert.org/account.php
PHP Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /www/includes/general.php on line 87, referer: https://secure.cacert.org/account.php
PHP Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /www/includes/loggedin.php on line 46, referer: https://secure.cacert.org/account.php
PHP Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in /www/includes/general.php on line 618, referer: https://www.cacert.org/account.php
PHP Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in /www/includes/lib/general.php on line 41, referer: https://secure.cacert.org/account.php
PHP Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in /www/includes/notary.inc.php on line 1291, referer: https://secure.cacert.org/account.php?id=50&userid=297249&csrf=25635229e752b5c92cadbb0eefb455ec&ticketno=a20140322.1
PHP Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in /www/www/index.php on line 140, referer: https://www.cacert.org/index.php?id=5

(0004925)
felixd   
2014-08-08 23:38   
I have commits that are suitable for the "ereg" and "Undefined index: oldlocation" errors.

https://github.com/yellowant/cacert-devel/commits/bug-1260


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1527 [Main CAcert Website] certificate issuing major always 2021-05-21 13:58 2021-05-24 16:29
Reporter: alkas Platform: Default  
Assigned To: OS: any  
Priority: high OS Version: any  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Debian package needs to be upgraded
Description: Debian package ca-cacert (2019.0411-2) needs to be upgraded!
(file ca-cacert_2019.0411-2_all.deb)
Tags: ca-cacert, class3, debian-package
Steps To Reproduce: 1. Download the file via https://packages.debian.org/sid/ca-cacert
2. Unpack the file, locate CAcert roots
3. Serial # of class3 is 0E. (and root - #0F is OK)
4. Serial # of class3 should be 14E228.
Additional Information:
System Description Default profile.
Attached Files:
Notes
(0006004)
jandd   
2021-05-21 16:59   
@alkas the Debian package is not maintained by CAcert, please file a bug report against the Debian package using

reportbug ca-cacert
(0006010)
alkas   
2021-05-22 12:25   
Already submitted:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988512
contains:
Debian Bug report logs - #988512
ca-cacert: class3 certificate will expire soon (on May 20 17:48:02 2021 GMT)
version graph
Package: ca-cacert; Maintainer for ca-cacert is Dmitry Smirnov <onlyjob@debian.org>; Source for ca-cacert is src:ca-cacert (PTS, buildd, popcon).
Reported by: Johannes Schulz <js@mailplus.co.at>
Date: Fri, 14 May 2021 13:03:02 UTC
Severity: normal
Tags: patch
Found in version ca-cacert/2019.0411-2
From: Johannes Schulz <js@mailplus.co.at>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: ca-cacert: class3 certificate will expire soon (on May 20 17:48:02 2021 GMT)
Date: Fri, 14 May 2021 14:58:33 +0200

Package: ca-cacert
Version: 2019.0411-2
Severity: normal
Tags: patch
(...)
Dear Maintainer,

`openssl x509 -noout -enddate -in /usr/share/ca-certificates/CAcert/class3_X0E.crt`
says: notAfter=May 20 17:48:02 2021 GMT

cacert has recently issued a replacement which can be downloaded here:
        https://www.cacert.org/class3.crt

See also http://blog.cacert.org/2021/05/re-signed-class-3-certificate-take-
action-now/

Please put the new certificate in the package.
(...)
(0006011)
dops   
2021-05-24 16:29   
A debian bug is already filed as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988512 . (As Debian packages must be signed by Debian people, CAcert can't provide this directly.)

Any Debian developer around?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1517 [Main CAcert Website] website content feature always 2021-04-21 20:25 2021-05-11 19:30
Reporter: jandd Platform: Main CAcert Website  
Assigned To: egal OS: N/A  
Priority: high OS Version: stable  
Status: solved? Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: egal, Ted
Test Instructions:
Summary: Rewrite Rules for new class3 certificate
Description: The new class3 certificate that has been issued on Monday 2021-04-19 contains the following URLs that need to be mapped on the main CAcert.org website:

CRL URI: https://www.cacert.org/class3.crl
CA Issuers: http://www.CAcert.org/class3.crt

The first URL should be mapped to https://crl.cacert.org/class3-revoke.crl and the certificate itself should be made available as http://www.cacert.org/class3.crt.

Please add the following RewriteRule in the https VirtualHost:

Rewrite "^/class3.crl$" "/class3-revoke.crl" [PT]

Please put the certificate cacert_2021.crt as class3_2021.crt into the $DOCUMENT_ROOT/certs folder and add the following RewriteRule in the http VirtualHost

Rewrite "^/class3.crt$" "/certs/class3_2021.crt" [PT]
Tags:
Steps To Reproduce:
Additional Information:
System Description Production version of the CAcert website
Attached Files:
Notes
(0005988)
egal   
2021-04-25 11:18   
(Last edited: 2021-04-25 11:18)
Tested in my test environment, Review successful
(0005995)
Ted   
2021-05-09 10:03   
(Last edited: 2021-05-09 18:55)
Hmm, this is a pure config change, so maybe Software Development is (IMHO) not the ideal department to review it... But as we don't have any alternatives I'd agree that a review by Software Development is better than none.

I have not evaluated the necessities of this change, but Jan's proposals sound plausible.

I did not find a "Rewrite" directive in the Apache documentation at http://httpd.apache.org/docs/current/mod/mod_rewrite.html , so I have nothing to review this proposal against. In this context, the review is a FAIL.

Assuming that I did overlook something and "Rewrite" is indeed some alias or abbreveation for the directive "RewriteRule", the rules are sensible, including the [PT] ("Passthrough") flag. For clarity it might be better to explicitly add the L ("last") flag, which is implied by [PT], so I'd propose to make it "[L,PT]" instead. But I don't consider this as critical.

Evaluation of the flags was based on Apache's documentation at https://httpd.apache.org/docs/2.4/rewrite/flags.html
(0005998)
egal   
2021-05-10 17:03   
(Last edited: 2021-05-10 17:04)
The following rules are already active on www.cacert.org to redirect CRL-requests:

  Redirect permanent /revoke.crl http://crl.cacert.org/revoke.crl
  Redirect permanent /class3-revoke.crl http://crl.cacert.org/class3-revoke.crl

So we could avoid adding new redirection for CRL and/or CSR and simply use the existing ones.

But ... we shouldn't forget to change https://www.cacert.org/index.php?id=3 to link to the new certificate
(0006000)
jandd   
2021-05-11 07:04   
@egal the existing ones do not cover the URLs mentioned in the new class3 certificate

CRL URI: https://www.cacert.org/class3.crl
CA Issuers: http://www.CAcert.org/class3.crt

We need to make the CRL and certificate available at these places to allow validation by clients that use these certificate fields for discovery.

@Ted you are right. It should be RewriteRule instead of Rewrite and [L,PT] is a good idea indeed
(0006001)
Ted   
2021-05-11 07:11   
So, for the "RewriteRule" directive this is a PASS from me.
(0006002)
egal   
2021-05-11 08:33   
No objection from my site
(0006003)
egal   
2021-05-11 19:29   
(Last edited: 2021-05-11 19:30)
Added

  RewriteRule "^/class3.crl$" "/class3-revoke.crl" [L,PT]
  RewriteRule "^/class3.crt$" "/certs/class3_2021.crt" [PT]

to all VirtualHosts in cacert.conf (after making a backup of original file).

Installed resigned class3-certificate as

  class3_2021.crt

Restarted Apache and verified downloads (successfully)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1499 [Main CAcert Website] certificate issuing feature N/A 2020-12-25 08:55 2021-04-25 11:15
Reporter: jandd Platform: Main CAcert Website  
Assigned To: Ted OS: N/A  
Priority: normal OS Version: stable  
Status: solved? Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: egal
Test Instructions: Apply the described procedures on a test system.
Summary: Resign class3 CA certificate before May 2021
Description: The current class3 CA certificate expires in May 2021. It should be renewed before expiry.
Tags: certificates, signer
Steps To Reproduce:
Additional Information: instructions for renewal an a matching OpenSSL configuration file are attached to this ticket. Additional issues should be filed for adapting WebDB, Mail templates, marketing material, monitoring and other places.

The signer has openssl 0.9.8o and tests should be performed using an equally old version.
System Description Production version of the CAcert website
Attached Files: README.md (11,968 bytes) 2020-12-25 08:55
https://bugs.cacert.org/file_download.php?file_id=488&type=bug
sign_class3_ca.cnf (1,933 bytes) 2020-12-25 08:55
https://bugs.cacert.org/file_download.php?file_id=489&type=bug
Notes
(0005948)
jandd   
2021-01-31 11:26   
please review the attached README and openssl configuration
(0005985)
egal   
2021-04-17 18:08   
The process could be processed as described, but with the following change:

No files should be copied TO the signer machine.

Therefore:
The existing signature-config should be copied on the signer to the new name and modified to match the content the config-attached to this bug.
(0005986)
egal   
2021-04-25 11:12   
The new certificate was created during the visit at BIT datacenter on 2021-04-19.

It's now in testing (e.g. installed) on our (internal) environment/servers.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1438 [Main CAcert Website] certificate issuing minor always 2018-04-17 15:24 2021-04-25 11:15
Reporter: wytze Platform: Default  
Assigned To: egal OS: any  
Priority: normal OS Version: any  
Status: solved? Product Version: 2017 Q4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2017 Q4  
Reviewed by: egal, Ted
Test Instructions: See Steps To Reproduce
Summary: CRLs published by CAcert do not contain the field "CRL number"
Description: EBS EDI-Support <EDI-Support@eon.com> reported on April 16, 2018:

the CRL which you are publishing at URL "http://crl.cacert.org/revoke.crl" is missing the field "CRL number".
Therefore some applications might not validate the CRL correctly. Please add this field to the CRL. Thank you.
Tags: certificates
Steps To Reproduce: $ wget http://crl.cacert.org/revoke.crl
$ openssl crl -in revoke.crl -inform der -noout -text -crlnumber | head

Something like this will appear:
crlNumber=<NONE>
Certificate Revocation List (CRL):
        Version 2 (0x1)
    Signature Algorithm: sha512WithRSAEncryption
        Issuer: /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
        Last Update: Apr 17 14:28:54 2018 GMT
        Next Update: Apr 24 14:28:54 2018 GMT
Revoked Certificates:
    Serial Number: 11
        Revocation Date: Apr 1 14:25:08 2003 GMT

The crlNumber=<NONE> shows the problem.
Additional Information: According to RFC 5280 (May 2008), section 5.2:
   Conforming CRL issuers are REQUIRED to include the authority key
   identifier (Section 5.2.1) and the CRL number (Section 5.2.3)
   extensions in all CRLs issued.

The same requirement was already present in the predecessor of this RFC, namely RFC 3280 from April 2002, so it is somewhat surprising that this was never implemented in the CAcert signer.

This can be fixed by adding the crlnumber field to the openssl profile used on the CAcert signer for generating CRLs. The openssl software used for this is capable of maintaining a serial number per CRL in a separate text file, see the documentation for 'openssl ca'.
System Description Default profile.
Attached Files: diff-openssl (588 bytes) 2018-05-29 10:02
https://bugs.cacert.org/file_download.php?file_id=423&type=bug
diff-class3 (586 bytes) 2018-05-29 10:02
https://bugs.cacert.org/file_download.php?file_id=424&type=bug
revoke.crl (332,445 bytes) 2018-06-06 09:29
https://bugs.cacert.org/file_download.php?file_id=425&type=bug
class3-revoke.crl (331,946 bytes) 2018-06-06 09:29
https://bugs.cacert.org/file_download.php?file_id=426&type=bug
testresult (958 bytes) 2018-06-06 10:51
https://bugs.cacert.org/file_download.php?file_id=427&type=bug
revoke-2.crl (332,445 bytes) 2018-06-07 21:03
https://bugs.cacert.org/file_download.php?file_id=428&type=bug
class3-revoke-2.crl (331,946 bytes) 2018-06-07 21:03
https://bugs.cacert.org/file_download.php?file_id=429&type=bug
testresult-2 (1,820 bytes) 2018-06-07 21:14
https://bugs.cacert.org/file_download.php?file_id=430&type=bug
diff-crlnumber-CA (132 bytes) 2018-06-13 22:10
https://bugs.cacert.org/file_download.php?file_id=431&type=bug
diff-crlnumber-class3 (132 bytes) 2018-06-13 22:10
https://bugs.cacert.org/file_download.php?file_id=432&type=bug
diff_Old_New (3,820 bytes) 2018-11-10 12:40
https://bugs.cacert.org/file_download.php?file_id=447&type=bug
diff_Old-Prod_Old-Test (2,686 bytes) 2018-11-10 12:40
https://bugs.cacert.org/file_download.php?file_id=448&type=bug
diff_New-Prod_New-Test (2,894 bytes) 2018-11-10 12:40
https://bugs.cacert.org/file_download.php?file_id=449&type=bug
Notes
(0005584)
wytze   
2018-04-17 15:36   
This can be tested with the signer installed on test.cacert.org.
(0005591)
GuKKDevel   
2018-05-29 09:57   
as the revoke-request only uses one configfile for each rootcert for creating the CRL, only those two have to be changed.
 
(0005592)
GuKKDevel   
2018-05-29 10:02   
Also must in each cert-directory (/etc/ssl/CA and /etc/ssl/class3) a file named crlnumber be created including a four digit number (echo 1000 > crlnumber)
(0005593)
egal   
2018-06-06 09:29   
Expected test is not possible as test.cacert.org will redirect the CRL-download to Live-System.

Test is only possible by accessing the test-server directly to get the CRLs for our test-environment.

As this is not possible for testers, I added the created CRLs for today (2018-06-06) to this bug, so a tester may check the existence of the missing CRLNumber.

In the next days I'll add another CRL-set so a tester can run its tests.
(0005596)
GuKKDevel   
2018-06-06 10:51   
tested: revoke.crl -> crlNumber=1249 (hex) -> X509v3 CRL Number: 4681 (dec)
tested: class3-revoke.crl -> crlNumber=010008 (hex) -> X509v3 CRL Number: 65544 (dec)

looks ok to me
(0005598)
egal   
2018-06-07 21:03   
Second set of CRLs as of today (2018-06-07).
(0005599)
GuKKDevel   
2018-06-07 21:14   
works for this CRL's also
(0005600)
Ted   
2018-06-13 20:44   
I just did some review of the proposed changes.

The modification of the config files is ok, according to OpenSSL documentation, as well as according to tests I did in another environment.

But for installation, a file containing the initial CRL number (probably 01 or 0100 or something similar) must be installed together with the change in the config file, otherwise the config option is ignored.

==> The diffs should include the "crlnumber" file with a convenient initial number

==> The current review status from me is FAILED
(0005655)
Ted   
2018-11-05 21:53   
I modified the openssl config files for all client certificates, so the testserver is CRL Distribution Point.

Sadly, for server certificates the CRL Distribution Point is hardcoded in server.pl, and I don't wand to change that without urgent need.
(0005661)
GuKKDevel   
2018-11-10 12:40   
As stated in https://bugs.cacert.org/view.php?id=1438#c5591 while revoking only two of the configurationfiles are used (openssl-client.cnf and class3-client.cnf).
Therefor for this issue only those two were to change. Also the necessary file crlnumber in the responding subdirectorys were to add.

attached diff: diff_Old-New

control if production and test are congruent:
diff_Old-Prod_Old-Test and diff_New-Prod_New-Test
(0005664)
Ted   
2018-11-12 19:43   
Hmm, the code in server.pl does not restrict revocations on those two specific configurations, but client.pl does only request those two.

I'm tending towards making all configurations fit to be used for revocation, just to be on the safe side, but I'm not really decided yet...
(0005975)
egal   
2021-04-05 17:55   
reviewed the configuration change successfully:

I don't have any objection adding these parameters to signer-configuration for two (or all) used root certificates
(0005977)
Ted   
2021-04-11 12:57   
I reviewed diff_Old_New once more, and now it is a PASS from me.
(0005987)
egal   
2021-04-25 11:13   
Patch installed on signer, new CRLs now contain a serial number


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1440 [Main CAcert Website] source code block N/A 2018-05-24 21:33 2021-04-13 10:09
Reporter: GuKKDevel Platform:  
Assigned To: Ted OS:  
Priority: immediate OS Version:  
Status: ready to deploy Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by: egal, Ted
Test Instructions:
Summary: link to EU-EEA-DataProtectionDeclaration
Description: we need a link to the EU-EEA-DataProtectionDeclaration
Tags: legal requirement
Steps To Reproduce:
Additional Information:
Attached Files: diff-bug-1440-bug-1440 (1,000 bytes) 2018-10-31 23:34
https://bugs.cacert.org/file_download.php?file_id=438&type=bug
Notes
(0005590)
GuKKDevel   
2018-05-24 21:55   
https://github.com/CAcertOrg/cacert-devel/compare/release...GuKKDevel:bug-1440
(0005623)
Ted   
2018-10-30 20:27   
The target link is https://wiki.cacert.org/Privacy/EU-EEE-DataProtectionDeclaration

The pages in the WiKi were created by Etienne, with some help of others.

I asked Megan (our current Privacy Officer) for a statement, she confirmed that at least the english text is acceptable.

Sent a Mail to Etienne asking about the current status, and his opinion on access restrictions on these pages.
(0005625)
Ted   
2018-10-30 22:23   
(Last edited: 2018-10-30 22:23)
The fix is now installed on https://test.cacert.org and ready for testing.

(0005627)
GuKKDevel   
2018-10-31 06:54   
did a short test.
irritating is that a certificate is asked for.
after giving one - connected with an account- , I am logged in to the wiki and the page is shown

cancel the certificate question the wikipage is shown

question:
can we at a later time integrate this pages into our online-directory?
or at least is the writing access to this wikipages restricted?
(0005629)
GuKKDevel   
2018-10-31 13:43   
tested with kubuntu 18.04 and firefox.
same behavior with win10 and chrome
same behavior with win10 and opera

different behavior win10 and firefox there was no question for certificate
(0005630)
L10N   
2018-10-31 22:59   
tested with Vivaldi 2.0 on Lubuntu 16.04 LTS
it tells something about invalid certs, if I accept to proceed to an unsure site it works.
If Vivaldi works this way, Chrome and Chromium will probabely as well.
(0005631)
L10N   
2018-10-31 23:12   
Can the text of the link be changed from EU-EEE-DataProtectionDeclaration to EU-EEA-DataProtectionDeclaration?
(This is a typo in the wiki URL, as EEA is the European Economic Area) - apperas the text on pootle and can be corrected an translated there?
(0005632)
GuKKDevel   
2018-10-31 23:34   
did the source change
(0005639)
Golffies   
2018-11-02 10:07   
Test report:

1. Tested URL: https://test.cacert.org

2. Hyperlink to GDPR visible in the footer of the main page with the label "EU-EEE-DataProtectionDeclaration".

3. Clicking on that link opens in the same window the page titled "PrivacyEU-EEE-DataProtectionDeclaration".
That page lists 7 languages, whom 4 of them make actually a GDPR declaration available.

4. Clicking on "english" opens in the same window the page titled "Data Protection Declaration for Users in EU & EEA". That page actually contains a declaration of CACert in regards of its users' rights and CACert's obligations under the general data protection regulation.

5. Coming back to the page titled "Data Protection Declaration for Users in EU & EEA" and then clicking on "česky" or "deutsch" directs in a similar way to the same declaration translated into theses respective languages.

6. Coming back to the page titled "Data Protection Declaration for Users in EU & EEA" and then clicking on "italiano" directs in a similar way to the same declaration partially translated into Italian, part of the declaration being displayed in English still.

7. Coming back to the page titled "Data Protection Declaration for Users in EU & EEA" and then clicking on "Български" or "français" or "nederlands" directs to empty pages (populated either by the generic message "This page does not exist yet." either by a message "translation to be completed").

8. Conclusion : the patch works like it should work. Additional work have to be done for completing translations of the GDPR declaration, but this is not what the patch is involved in.

9. Tested with Firefox Quantum 63.


Miscellaneous : that test report was written as a matter of exercise for me, in order to find in the future a trade-off between the quality of software testing required by CACert's policy and the quantity of work it requires from tester. Here, it might happen that the amount of paperwork coming with the patch acceptance far exceeds the quantity of work for writing the patch itself.

May it be enough for a second confirmation test by someone else to states that the same behaviour would have been observed, without more details? I hope so, in order to save time of the next tester.
(0005640)
GuKKDevel   
2018-11-02 11:02   
if the new diff (https://bugs.cacert.org/view.php?id=1440#c5632; EU-EEE-DataProtectionDeclaration to EU-EEA-DataProtectionDeclaration) is installed, the wiki-page(s) must be renamed:
PrivacyEU-EEE-DataProtectionDeclaration to PrivacyEU-EEA-DataProtectionDeclaration
(0005656)
L10N   
2018-11-05 23:43   
The following links are now changed:
https://wiki.cacert.org/Privacy/EU-EEA-DataProtectionDeclaration
https://wiki.cacert.org/Privacy/EU-EEA-DataProtectionDeclaration/CZ
https://wiki.cacert.org/Privacy/EU-EEA-DataProtectionDeclaration/DE
https://wiki.cacert.org/Privacy/EU-EEA-DataProtectionDeclaration/EN
https://wiki.cacert.org/Privacy/EU-EEA-DataProtectionDeclaration/FR
https://wiki.cacert.org/Privacy/EU-EEA-DataProtectionDeclaration/NL
https://wiki.cacert.org/Privacy/EU-EEA-DataProtectionDeclaration/IT
including the internal links on the top of each page.
(0005659)
GuKKDevel   
2018-11-06 10:54   
L10N proposed to solve bug-1423 i the same test as bug-1440;

Wenn du gerade den Datenschutzlink auf der Cacert.org Seite änderst,
könntest du gleich eine Zeile darüber bei de Sponsorenlogos beim Open
Network Architecture Logo den Link zu
http://www.openarchitecturenetwork.org/ entfernen?

Das Netzwerk existiert nicht mehr und der Link wird zu einer Bank in
Singapur umgeleitet, zu der CAcert keine Beziehung hat. Somit wäre
https://bugs.cacert.org/view.php?id=1423 auch gerade gelöst.

The branch is created and updated
(0005839)
sss   
2019-09-21 15:44   
tested on:
mozilla firefox 69.0.
i do not have wiki account yet.
certificate requested on click (but looks like it does not requested anymore after i logged in to mantis).
i do not see problem in certificate requesting, but if anonymous access to this page must be provided, in case of not providing login certificate page should be displayed too.
(0005840)
sss   
2019-09-21 15:46   
i have logged out from mantis and retry test, certificate does not requested anymore.
(0005841)
sss   
2019-09-21 15:48   
certificate requested again after browser restart, page works in both cases:
1. if i provide login certificate
2. if i decline and does not provide login certificate
(0005842)
SaT   
2019-09-21 18:18   
Tested with FF 69.0 (64 bit) on Linux Mint 19.2. I have a Wiki account.
I startet FF and clicked the link, got a client certi dialog. I pressed ESC and got to the Wiki. Clicked "deutsch" and got to Datenschutzerklärung without more client cert dialog.
I restarted FF and clicked the link, this time I chose my certificate and got into the Wiki (login successful).
I restart FF a third time and opened the link as HTTP. The Wiki link is HTTPS, so it will always request a client cert.

I'm ok with this behaviour (as the privacy declaration can be accessed without certificate).
You could improve it only if the Wiki would allow HTTP and had no Strict-Transport-Security header.
(0005843)
SaT   
2019-09-21 18:33   
Now tested on my LineageOS 14.1 phone (1080 x 1920). I have CAcert root certs installed.
First with FF 68.1.1: Works without client cert dialog, I get to the privacy declaration with 2 clicks.
Strange: Android browser shows the welcome page, but when I click the link it loads the Wiki, but does not display it. There is still the welcome page displayed.
I guess this is an Android/LIneageOS issue and no CAcert bug.
(0005849)
Ted   
2019-10-02 19:26   
So, I take this testreports that this procedure is acceptable. So now, reviews must be done (by the Software Assessors)...
(0005973)
egal   
2021-04-05 17:38   
review passed when using the code from test-server:
  <div id="siteInfo">
        <a href="//wiki.cacert.org/FAQ/AboutUs"><?=_("About Us")?></a> | <a href="/index.php?id=13"><?=_("Donations")?></a> | <a href="http://wiki.cacert.org/wiki/CAcertIncorporated"><?=_("Association Membership")?></a> |
        <a href="/policy/PrivacyPolicy.html"><?=_("Privacy Policy")?></a> |
        <a href="https://wiki.cacert.org/Privacy/EU-EEA-DataProtectionDeclaration"><?=_("EU-EEA-DataProtectionDeclaration")?></a> |
        <a href="/index.php?id=51"><?=_("Mission Statement")?></a> | <a href="/index.php?id=11"><?=_("Contact Us")?></a> |
        ©2002-<?=date("Y")?> <?=_("by CAcert")?></div>
</div>
(0005978)
Ted   
2021-04-11 14:31   
Rebased bug-1440 to the current release branch.

Compared commits d328ebd6ad641a9caf4c80208a14d3b8f768edc0 (release) to cc57914d34e703c2abd085757bd91d9d6313e92e. The review is PASSED.

I noticed that https://wiki.cacert.org/Privacy/EU-EEA-DataProtectionDeclaration/DE (and probably the translations as well) need an update to the new (swiss based) address of CAcert Inc, but this does not prevent the review.
(0005979)
Ted   
2021-04-11 16:08   
Patch request sent to critical team.
(0005980)
jandd   
2021-04-12 07:41   
@Ted where can I find a git branch containing commit cc57914d34e703c2abd085757bd91d9d6313e92e ? I would like to discuss how we do branching/releasing correctly and most importantly in a traceable manner in the future. Sending around individual patches may not be the best way to do this.
(0005981)
Ted   
2021-04-12 16:10   
(Last edited: 2021-04-12 16:11)
@jandd You can use "git show cc57914d34e703c2abd085757bd91d9d6313e92e" to get details on the commit (for example the branches where this commit is included),
you can usr "git checkout cc57914d34e703c2abd085757bd91d9d6313e92e" to get the code status after this commit, you can use it as one parameter for "git diff".

With Git Extensions you can explicitly search for the commit.

For github.com I did not find a way to easily search for a commit id (without knowing its branch)...

Does this answer your immediate question?

As I understand it, the commit id is one reliable mechanism to refer to a specific code state in git.
I'm very open to discuss alternatives to my current processes, but I guess this case is not the ideal place to do so... Should we try on cacert-devel@lists.cacert.org ?
(0005982)
jandd   
2021-04-13 10:09   
I just was not aware that searching for commit ids does not work on github. https://github.com/CAcertOrg/cacert-devel/compare/bug-1440 shows the change. Sorry for the noise :-)

git branch -a --contains cc57914d34e703c2abd085757bd91d9d6313e92e

showed me the relevant branch.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1287 [Main CAcert Website] block N/A 2014-06-27 22:35 2021-04-05 18:04
Reporter: olea Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Inclusion in Fedora of CAcert root cert
Description: CAcert root certificate can't be included into Fedora due to legal requirements.

Citing Spot:

«It seems clear from the lack of response to my query that no one from CAcert that is posting on this ticket is a lawyer.

»Red Hat has lawyers who review license issues, whether they be on content, code, certificates, or greased ferrets. They've reviewed the CAcert terms and advised us that they do not meet the minimum requirements for Fedora to include them.

»If there is an actual lawyer on the CAcert side who would be willing to correspond with Red Hat Legal on this issue, please feel free to either have them reach out to me, or send me their contact information and I will be sure to connect them with Red Hat Legal.»

https://bugzilla.redhat.com/show_bug.cgi?id=474549#c59

I'm open to help some qualifed one to discuss this with the Fedora/Redhat team.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1423 [Main CAcert Website] website content trivial always 2017-02-16 09:30 2021-04-05 17:31
Reporter: L10N Platform: Default  
Assigned To: Ted OS: any  
Priority: normal OS Version: any  
Status: needs review Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Link to an Asian Loan Bank
Description: On the bottom of cacert.org are some logos with links to this organisations as bit, tunix, nlnet, but also open architecture networtk. The open architecture networtk does not exist anymore and the url is redirected to a loan bank institut in Singapore (https://easycredit.com.sg/moneylenders/).

A. The OAN logo should be removed.
B. If the bank pays some subsidies to CAcert, the logo should be replaced by their own logo.
Tags:
Steps To Reproduce:
Additional Information:
System Description Default profile.
Attached Files: sponsorinfo.php (744 bytes) 2020-08-10 14:17
https://bugs.cacert.org/file_download.php?file_id=483&type=bug
Notes
(0005540)
Eva   
2017-03-10 18:18   
I confirm that the link is pointing to a bank, now, which does not seem to have a specific relation to the original project. Further a quick search of mine did not provide any indication that the project continues to be active, but the search was not in depth.

Howerver I believe that about adding and removing of sponsors, board should decide. I advise to request for a confirmation that this should be done by board, before such a fix is done. They also should be those who know if it would be correct to remove the link or to let it point to a new destination of the project (or the correct destination of the bank, but I doubt that).
(0005541)
Eva   
2017-03-10 18:43   
I asked board via public mail how the correct solution would look like:
a) deleting the complete link, including the logo
b) fixing the link to a new location
c) changing the link to directly point to that bank, with correct logo
(probably not desired)
(0005657)
L10N   
2018-11-06 00:05   
The solution should be: remove the link from the logo. The logo itself can remain for the moment (until board decided how to deal with this logos).
(0005658)
L10N   
2018-11-06 00:06   
This problem could be solved together with 0001440. GuKK Devel, can you do that? I am willing to review.
(0005846)
Ted   
2019-09-26 20:43   
Branch bug-1423 is now merged into the testserver installation and can be tested.

Test is quite easy: verify that the Open Architecture Logo ir removed from the bottom of the start page https://test.cacert.org/
Maybe verify that the logo is on no other page.
(0005847)
L10N   
2019-09-26 22:26   
I tested it:
1. Opened https://test.cacert.org/
2. scrolled down
3. did see 3 logos, but not that one from OpenArchitecture.

-> OK
(0005848)
GuKKDevel   
2019-09-27 09:28   
opened test.cacert.org
got the main page with logo of openarchitecture not shown.

looks as expected --> OK
(0005850)
Ted   
2019-10-02 19:28   
Minimum test reports are reached (which should be enough for such a simple change, but don't hesitate to post your report nevertheless!), so I'm putting this in status "needs review"...
(0005904)
L10N   
2020-08-10 12:23   
I completely forgot that I had already tested it and did it again in code on behalf of whatever:
- replaced the link from OpenArchitecture
- added another logo (Cacert) with Link to our wiki page with the smaller sponsors
/includes/sponsorinfo.php
(0005905)
L10N   
2020-08-10 12:31   
I completely forgot that I had already tested it and did it again in code on behalf of egal:
- removed the broken link from OAN
- ad another Logo (CAcert) with link to the wikipage with other sponsors

/includes/sponsorinfo.php
(0005906)
L10N   
2020-08-10 12:51   
Egal asked me to do that (and I didn't remember, that it was already done and I was one of the reviewers). In the attached code is a difference:
- broken link removed (similar)
- new CAcert logo added with link to wiki sponsor page
/includes/sponsorifno.php
(0005907)
L10N   
2020-08-10 14:17   
Egal asked me to do that (and I didn't remember, that it was already done and I was one of the reviewers). In the attached code is a difference:
- broken link removed (similar)
- new CAcert logo added with link to wiki sponsor page
/includes/sponsorifno.php
(0005972)
egal   
2021-04-05 17:31   
sponsorinfo on testserver is different to the attached one:

    <img class="sponsorlogo" src="/images/oan.png" alt="[OAN logo]" border="0"></a>
    <a href="http://wiki.cacert.org/FAQ/AboutUs/History#Sponsors" target="_blank"><img class="sponsorlogo" src="/images/cacert4.png" alt="[OAN logo]" border="0"></a>

To fix:
OAN-Image shold be removed, too
Sponsor-Logo for the link to wiki should not be CAcert (maybe completely remove the image and add "more" (or another text) for the link)
If an Image should be kept, please adjust the alt-text


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1505 [Main CAcert Website] certificate issuing major always 2021-02-05 17:28 2021-03-08 13:52
Reporter: alkas Platform: Default  
Assigned To: Ted OS: any  
Priority: normal OS Version: any  
Status: new Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: The main web, the "New Client Certificate" page, refers to the controversial Wiki article
Description: The page in question is "https://secure.cacert.org/account.php?id=3" with the "Advanced settings" checkbox checked.
On the page, you can see the "Add SSO ID" checkbox with some text and the link "http://wiki.cacert.org/wiki/SSO". The very first sentence of the referred article is: "This page needs to document SSO or it will be removed!!!!" !
That Wiki page should describe SSO capability of certificates, as an user can expect.
Tags: new client certificate, SSO, Wiki
Steps To Reproduce: Try to create a new client certificate. Find and use the link stated above. Read and evaluate the Wiki article.
Additional Information:
System Description Default profile.
Attached Files:
Notes
(0005958)
alkas   
2021-02-14 17:36   
Added 2 proposals for an article about SSO with client certificate: SSO2 and SSO2/CZ. Please read and comment those. AK
(0005960)
bdmc   
2021-03-03 13:08   
I agree with the assessment of the original "SSO" Wiki page. After reviewing Ales' new version of a page, a very comprehensive description of SSO and its relationship to Certificates, I recommended that the two pages be swapped, preserving the original, but replacing it so that the link in the Advanced Options gives useful information.
(0005961)
alkas   
2021-03-03 18:36   
Done.
(0005962)
Ted   
2021-03-08 13:51   
Spam...
(0005963)
Ted   
2021-03-08 13:52   
Sorry, falscher Case...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1506 [Main CAcert Website] web of trust feature N/A 2021-02-13 17:17 2021-02-20 04:19
Reporter: Ted Platform:  
Assigned To: japh OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Implement some notification for Assurers to destroy CAP forms 7 years after an Assurance
Description: Since we came to the conclustion that CAP forms should be destroyed 7 years after an Assurance (see <https://wiki.cacert.org/AssuranceHandbook2#What_about_that_CAP_form.3F> and <https://blog.cacert.org/2021/01/destroying-the-cap-form/>), @japh has proposed to implement a notification mechanism to assist Assurers with this.

Several options seem to be available, including but not limited to:
- Notification by e-mail
- Notification on the web page when logging in to the CAcert account

We should try to collect more detailed requirements and specifications here before starting implementation.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0005959)
japh   
2021-02-20 04:19   
Proposed changes:

comments and suggestions welcome!

1. prepare a standard email template
    - include placeholders for recipient and perhaps the number of expired
        assurances since last login or last reminder
    - should be as succinct / concise as possible
    - e.g.
            <number> of your CAcert assurances have recently past their required,
            7 year retention age.
            In the interests of data security (e.g. GDPR), please destroy any
            CAP forms in your possession which are older than 7 years.
    - inform the assurer that they can change their reminder preference via
        their cacert.org "My Alert Settings" page.
    - the reminder email should NOT contain any personal information
        (except the repient's email (and name?))
    - don't assume english - use `users.language` to automatically select
        appropriate language?
    - reminder text should be available in all supported languages (help needed!)

2. add a new alert preference flag, e.g. `alerts.cap_expiry`
    - only relevant => visible for assurers, via their "My Alert Settings" page
    - when set, allow CAcert to send a reminder email when assurances made by
        the assurer have "recently become 7 year old" (expired)
    - allows at most e.g. 1 reminder email per month
    - default 'on' for existing members? (otherwise we wouldn't send any reminders)
        OR, set default NULL, send exactly 1 reminder if the flag is NULL and
        then automatically set the flag to "off".
        This would mean that active assurers are informed that they can opt-in
        to getting reminders emails.
        Inactive assurers get a one-off reminder and then automatically return
        to being inactive. i.e.: no need for them to do anything to remain inactive.

3. write a new script to send reminders, based on existing notification scripts.
    - may be run daily (for 1/28'th of the assurers) or monthly (over all assurers)
    - identify expired assurances by comparing `notary.date`, `notary.when`
        or `notary.expire` against "now - 7 years"
        (which field would be most appropriate?)
    - DO NOT send emails to assurers who received a reminder recently, or
        logged in since the most recent assurance expiry
    - appropriate fields to check?
            users.lastLoginAttempt
            notary.date
            notary.when
            notary.expiry
    - add new date record
            e.g.: users.last_cap_expiry_reminder (date)
    - query to find people to send reminder to:
            e.g.: (sample only)

                with
                cutoff as (
                    select
                        users.id,
                        max( users.last_cap_expiry_reminder, users.lastLoginAttempt ) as last_reminder
                    from users
                    group by users.id
                    )
                select
                    users.email,
                    count(*) as num_expired
                from
                    users
                    join notary on notary.from = users.id
                    join cutoff on cutoff.id = users.id
                where
                    -- correct reference date?
                    -- notary.date
                    -- or notary.when
                    -- or notary.expired
                    notary.date > date_sub( cutoff.last_reminder, interval 7 years )
                group by
                    users.email

4. add a prominent reminder to login pages
        e.g.:
            https://secure.cacert.org/account.php
            https://secure.cacert.org/account.php?id=36 ("My Alert Settings" page)
            https://secure.cacert.org/wot.php?id=10 ("My Points" page - add new column "Destroy CAP Form (y/n)" ?)
    - use text similar to the reminder email
    - only display reminder if assurances have expired since the last login
        assume that emails have been lost in transit
        or provide positive confirmation that the email received was not sent
        erroneously / maliciously
    - use similar query to above, but only check last login date
    - ignore logins on same day, i.e.: prevent edge case of
        failed/short/interrupted login automatically cancelling the UI reminder.
        Keyword: "de-bounce"
    - I do not envision a requirement for assurers to confirm CAP form destruction


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1507 [Main CAcert Website] web of trust tweak always 2021-02-20 00:59 2021-02-20 00:59
Reporter: japh Platform: Main CAcert Website  
Assigned To: japh OS: N/A  
Priority: normal OS Version: stable  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Replace "should" with "must" in statements regarding deletion of CAP forms after 7 years
Description: The GDPR requires that all unneccessary documentation be destroyed within a reasonable amount of time.
To clarify this, all statements regarding the destruction of CAP forms should use an imperitive statement, instead of the current implicit statements. This includes the statements on the CAP forms themselves.

In other words: "the CAP forms must be destroyed after 7 years" instead of "the CAP forms should (or may) be destroyed after 7 years".

See also:
issue 0001506
https://blog.cacert.org/2021/01/destroying-the-cap-form/
https://wiki.cacert.org/AssuranceHandbook2#What_about_that_CAP_form
Tags:
Steps To Reproduce:
Additional Information:
System Description Production version of the CAcert website
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1502 [Main CAcert Website] web of trust major always 2021-01-13 16:05 2021-02-03 13:09
Reporter: alkas Platform: Default  
Assigned To: OS: any  
Priority: normal OS Version: any  
Status: new Product Version: 2015 Q3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Website CAcert.org should be more user friendly
Description: Many question for Support team concern few problems.
#1 - a common user is trying to get a client certificate e. g. for e-mail security. When s/he uses browsers like Firefox, Chrome, Edge, Safari etc,, s/he sees the following error message (roughly): No valid CSR received. Try another browser. The Wiki articles exist with solutions of just this. Will it be possible to add a link to the specific Wiki article?

The most frequent questions to Support:
. My browser is unable to create and submit CSR, (Wiki: https://wiki.cacert.org/HowTo/ClientCertCreate4)
- I am unable to renew my certificate (Wiki: https://wiki.cacert.org/FAQ/CertificateRenewal)
- My system reports the private key needed, where to find it (Wiki: https://wiki.cacert.org/FAQ/MissingPrivateKey)
- How to convert binary P10 formatted CSR to Base64 format (Wiki: https://wiki.cacert.org/HowTo/CertP10toBase64Coding)
- Digital signing of documents (e.g. Wiki: https://wiki.cacert.org/AdobeReader and more)
...and several other.
Tags: browser, Wiki, WoT
Steps To Reproduce: Try to make a client cert via Firefox browser. Look at the error message. The Wiki articles solving this are https://wiki.cacert.org/FAQ/Keygen, and https://wiki.cacert.org/HowTo/ClientCertCreate4
Additional Information:
System Description Default profile.
Attached Files: Screen Shot 2021-02-03 at 13.58.14.png (100,719 bytes) 2021-02-03 13:09
https://bugs.cacert.org/file_download.php?file_id=494&type=bug
Notes
(0005956)
Golffies   
2021-02-03 13:09   
Proposal for a quick but efficient fix.
It might look like that (consensus with Aleš and Dirk):

* change as least as possible the text of the UI, in order to avoid to change it in many langages at once

* make the checkbox "Show advanced options" checked by default (please see attached screenshot)

* add a default explanation text in the CSR input field (text box) where the CSR has to be pasted

* such a text might look like that:

  "Please pay attention that Certificate Signing Request is not optional anymore. It is mandatory to copy and paste a CSR into this box. The certificate generation won't work in case you do not provide a CSR. Please clear this text and paste your CSR here."

* ideally, such text should be in written grey, in the background of the CSR input field, then disapear by itself as soon as the user pastes a CSR or type any character in the input box.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1503 [Main CAcert Website] website content minor sometimes 2021-02-02 17:42 2021-02-02 22:14
Reporter: alkas Platform: Default  
Assigned To: OS: any  
Priority: normal OS Version: any  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions: Make an update of a Wiki article.
Summary: Updating Wiki article ends with "Gateway Timeout" very often
Description: After finishing an article update/new one, the web waits about 2-3 mins, then it reports the 504 Gateway timeout" error. Despite that, the article is saved. It's only that the 2-3 minutes of fear occurs.
Tags: Wiki;Gateway timeout;
Steps To Reproduce: Make an update of a Wiki article.
Additional Information:
System Description Default profile.
Attached Files:
Notes
(0005954)
Ted   
2021-02-02 19:00   
I can confirm this behaviour, which I have experienced for some months (? surely since December).

The changes are obviously saved "immediately", you can see them when opening the page in a different tab while the "saving" tab is still busy.
(0005955)
L10N   
2021-02-02 22:14   
If I heard correctly from a representative of the Critical Team, the reduced bandwidth is related to other things that are now being processed.
The problem can be easily worked around:
1. Save
2. wait 3-5s
3. reload page
In fact, the page hangs just after saving.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
356 [Main CAcert Website] certificate issuing feature always 2006-11-15 02:03 2021-01-31 11:41
Reporter: Sourcerer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: X509v3 Authority Key Identifier
Description: Those who need to trust my certificate claims it is required - otherwise their "proxy server" will not accept it
They say: On a signed certificate, running "openssl x509 -noout -text -in some.cert" somewhere in the output the following shold appear : "
X509v3 extensions:
            X509v3 Authority Key Identifier: keyid:9F:A9:16:E0:C9:FF:92:93:3B:F6:FE:60:BD:F5:13:49:3D:B2:3B:B1"
That section is not in my cacert issued server certificate.
Tags: baseline requirements, certificates, signer
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0000710)
navy   
2006-11-15 02:10   
It appears to be related to the OpenSSL conf item:
authorityKeyIdentifier = keyid,issuer:always
(0005951)
jandd   
2021-01-31 11:40   
This is still true in 2021, the extension is required by CAB Forum BR too and should be added to the signer configuration for all end entity certificates.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
996 [Main CAcert Website] certificate issuing minor have not tried 2011-12-02 08:52 2021-01-31 11:23
Reporter: jandd Platform: Main CAcert Website  
Assigned To: jandd OS: N/A  
Priority: normal OS Version: stable  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Slashes in OU value gets stripped (org cert)
Description: The original issue was reported to the project "Infrastructure" as http://bugs.cacert.org/view.php?id=995
Tags: signer, signer_client, webdb
Steps To Reproduce: see http://bugs.cacert.org/view.php?id=995
Additional Information: see http://bugs.cacert.org/view.php?id=995
System Description Production version of the CAcert website
Attached Files:
Notes
(0005947)
jandd   
2021-01-31 11:22   
This issue cannot be fixed with the current signer/web application because both use strings to pass the Subject DN information. The code needs to be reimplemented to support propert DER ASN.1 structures.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
878 [Main CAcert Website] misc major have not tried 2010-10-07 13:36 2020-12-21 19:02
Reporter: Uli60 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: replace locations-database-set with new dataset or alternate solution a20090427.2
Description: Ruling order:

iii. The Community shall start a project ASAP to migrate the location function that is currently implemented in the critical system, with the objective of replacing the locations database completely, by means of either
  * a) with a completely new fresh freely available open source
       of locations data
or
  * b) any alternate solution to the location function that does not need
       a local store of locations data within the critical system
Tags:
Steps To Reproduce:
Additional Information: its open to the developers how to solve this
e.g. outsource the service, replace the locations-database-set
or whatever solution fits
Problem confirmed and ruled to be a problem by Arbitration
https://wiki.cacert.org/Arbitrations/a20090427.2
Attached Files:
Notes
(0005927)
jandd   
2020-12-21 19:02   
users could enter their location with assistance from the nominatim API of OpenStreetMap https://wiki.openstreetmap.org/wiki/Nominatim

We would store the geo coordinates and could use queries to find assurers within proximity of a specific location similar to what is described in https://mariadb.com/de/resources/blog/mariadb-server-10-2-json-geojson-gis/


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1077 [CATS.cacert.org] User Interface minor always 2012-06-25 21:04 2020-12-09 11:36
Reporter: Lemming Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: (PHP) Fatal Error in includes/graph_bib/phplot.php
Description: The server cant create an image by clicking 'show as line chart' or 'show as bar chart' for watching your progress in challenges because of undefined functions.

Fatal error: Call to undefined function ImageCreate() in /home/cats/public_html/includes/graph_bib/phplot.php on line 233


Fatal error: Call to undefined function ImageDestroy() in /home/cats/public_html/includes/graph_bib/phplot.php on line 257
Tags:
Steps To Reproduce: * Login in CATS
* Click Progress
* Click 'show progress'
* Click 'show as line chart' or 'show as bar chart'
* Look at the sourcecode of this page and follow the URL of the <img>-tag with 'includes/graph_bib/curve.php..'
Additional Information:
Attached Files:
Notes
(0005923)
jachhunter777   
2020-12-09 11:36   
Fatal error: Call to undefined function ImageDestroy(https://goo.gl/2DqXGj) in /home/cats/public_html/includes/graph_bib/phplot.php on line 257

* Click Progress
* Click 'show progress'
* Click 'show as line chart' or 'show as bar chart'
* Look at the sourcecode of this page and follow the URL of the <img>-tag with 'includes/graph_bib/curve.php..'


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1469 [Main CAcert Website] misc major always 2019-10-11 10:38 2020-11-23 09:33
Reporter: mcgiwer Platform: Main CAcert Website  
Assigned To: Ted OS: Linux (Debian based)  
Priority: normal OS Version: stable  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions: see: Steps to reproduce
Summary: CACert.org certificate issues (with valid root certificates installed)
Description: 1. when I attempt to open cacert.org website pages, I recieve a following error every time:

> Secure Connection Failed
>
> An error occurred during a connection to cats.cacert.org. SSL peer was unable to negotiate an acceptable set of security parameters.
>
> Error code: SSL_ERROR_HANDSHAKE_FAILURE_ALERT
>
> The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
> Please contact the website owners to inform them of this problem."

===========

2. when I'm attempting to issue a client certificate, I recieve a following error:

> I didn't receive a valid Certificate Request, please try a different browser.

Please repeair above error's ASAP. Thanks
Tags:
Steps To Reproduce: Enter the website
Additional Information:
System Description Production version of the CAcert website
Attached Files:
Notes
(0005851)
Ted   
2019-10-14 08:09   
(Last edited: 2019-10-14 08:10)
Usually this is caused by the fact that the CAcert root certificates are not installed in the browser, see http://wiki.cacert.org/FAQ/Mess

If you have CAcert root certificates installed (and trusted), there are still occasional problems that the old version of the root certificate is somewhere in traffic, which still used MD5 for self-signature, see http://wiki.cacert.org/HowTo/ReplaceCAcertRootCertificate

If both of these possible causes are eliminated we'd need to know which browser you are using.

(0005852)
mcgiwer   
2019-10-14 09:03   
I use Firefox. Maybe it would be a good idea to make the main site load without SSL as default. This would partially solve the problem.

On the main website should be a information about need of installing the Root certificates to enter the SSL or install a SSL certificate with donsn't require doing that
(0005919)
mcgiwer   
2020-11-23 09:30   
I have removed the old and installed new root certificates of CA cert and independant from it:

1. when I attempt to open cacert.org website pages, I recieve a following error every time:

> Secure Connection Failed
>
> An error occurred during a connection to cats.cacert.org. SSL peer was unable to negotiate an acceptable set of security parameters.
>
> Error code: SSL_ERROR_HANDSHAKE_FAILURE_ALERT
>
> The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
> Please contact the website owners to inform them of this problem."

===========

2. when I'm attempting to issue a client certificate, I recieve a following error:

> I didn't receive a valid Certificate Request, please try a different browser.

Please repeair above error's ASAP. Thanks


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1455 [Main CAcert Website] GPG/PGP minor always 2019-01-09 01:10 2020-10-31 13:25
Reporter: colincogle Platform: Default  
Assigned To: OS: any  
Priority: normal OS Version: any  
Status: new Product Version: 2015 Q3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: CAcert cannot recognize or sign GPG/PGP keys with EdDSA public keys
Description: I finally created a new keypair with the newest version of GnuPG, and I used the EdDSA algorithm. However, CAcert cannot parse it. While it uploaded successfully, it's been stuck on "pending" for a while. Additionally, the expiration date shows as "0000-00-00 00:00:00."
Tags:
Steps To Reproduce: 1. Create a new EdDSA key with the command: gpg --full-generate-key
2. Upload it to CAcert in hopes of getting it signed.
Additional Information: I have not tested this with ECDSA, ECDH, or ElGamal keys. However, I'd wager that support for those newer types are also lacking.

I tagged this as minor/normal but as the new version of GnuPG trickles out, this may turn into a major/high issue.
System Description Default profile.
Attached Files: 2020-10-31 142414-CAcert_signed_GPG_key-Invalid_digest_algorithm.png (4,726 bytes) 2020-10-31 13:25
https://bugs.cacert.org/file_download.php?file_id=485&type=bug
Notes
(0005731)
Ted   
2019-01-09 15:48   
It's just a wild guess, but I assume that the version of GPG which is installed on the signer is a bit too old to know the new algorithms, does this sound plausible?
(0005732)
colincogle   
2019-01-09 17:39   
That's probably it. Support for ECDH, ECDSA, and EdDSA keys were added in GnuPG 2.1.
(0005856)
SaT   
2019-12-03 07:51   
I stumbled upon this bug today, too. A fresh GPG key with Elliptic Curves cannot be signed, it is pending forever. A RSA key does work.
(0005914)
NoSubstitute   
2020-10-31 13:25   
Signing "RSA key does work."

I wonder if that is still true, though.
I just signed my RSA key today, and when checking the signature in GPGWin it comes back as "Invalid digest Algorithm" where it should say who signed it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1493 [Main CAcert Website] website content minor always 2020-08-07 22:31 2020-09-16 21:19
Reporter: L10N Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: needs review & testing Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Replace Paypal button with IBAN bank account GRKB
Description: Instead of the Paypal buttons should be shown:
CAcert Inc bank account Europe (GRKB) CH02 0077 4010 3947 4420 0
CAcert Inc bank account Australia (Westpac) (already displayed)
-------
Bankenclearing: 774
BIC (SWIFT): GRKBCH2270A

Grisons Cantonal Bank, Coire, Switzerland
Graubündner Kantonalbank, Chur, Schweiz
Banque Cantonale des Grisons, Coire, Suisse
Banca Cantonal Grigione, Coira, Svizzera
Banca Chantunela Grischuna, Cuira, Svizra
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 0.php (5,507 bytes) 2020-08-10 12:15
https://bugs.cacert.org/file_download.php?file_id=479&type=bug
21.php (2,147 bytes) 2020-08-10 12:15
https://bugs.cacert.org/file_download.php?file_id=480&type=bug
13.php (2,381 bytes) 2020-08-10 12:15
https://bugs.cacert.org/file_download.php?file_id=481&type=bug
5.php (2,864 bytes) 2020-08-10 12:15
https://bugs.cacert.org/file_download.php?file_id=482&type=bug
Notes
(0005901)
L10N   
2020-08-10 11:31   
28.7.2020:
> Ich habe noch nie an der Homepage herumgeschraubt. Aber den Paypal-Knopf
> durch eine IBAN-Nummer zu ersetzen, das traue ich mir noch zu. Könntest
> du mir sagen, wo ich das finde? Vielleicht in einem GIT, wo ich dann
> eine Kopie erstelle, die die hohen Herren dann überprüfen können?
(0005902)
L10N   
2020-08-10 11:32   
29.7.2020:
So einfach ist das nicht ... ;-)

Du braucht eine Bug-Nummer dazu (Mantis) ... und lieferst idealerweise
direkt auch den Patch dazu mit.

Die Sourcen kannst du dir ohne git direkt von www.cacert.org runterladen
(muesste jetzt mal schauen, wo genau der Link ist ... aber irgendwo
"unten rechts").

Ted und ich koennen dann den entsprechenden Review machen, damit Ted das
dann an Critical (mich) schicken kann, damit das dann auch auf
www.cacert.org verewigt wird.

(Wenn du schonmal dabei bist: Wirf bitte bei den Sponsoren das Open
Architecture Network raus (das gibt es nicht mehr) und bau dort einen
Link auf eine Sponsorenseite im wiki ein, wo wir dann weitere (kleinere)
Sponsoren wie abilit.eu (von denen kam der "Luxemburg"-server) oder auch
Einzelpersonen nennen koennen.

machs guat

PS: Die genaue Datei muesste ich auch nachschauen ... wenn du aber die
sourcen hast, kannst du da mit "grep" nach suchen ... ;-)
(0005903)
L10N   
2020-08-10 12:15   
I replaced the paypal button code by the IBAN with the same coding as was given the information about the Westpac bank account:
/pages/index/0.php
/pages/index/13.php
/pages/index/21.php

Furthermore, I removed the paypal button code (it was there to pay for password reset, the link to the wiki remains):
/pages/index/5.php
(I am not shure if this is another bug, but it is an issue for long time.)
(0005910)
L10N   
2020-09-16 21:19   
Following https://wiki.cacert.org/Brain/CAcertInc/Committee/MeetingAgendasAndMinutes/2020-09-03#Minutes

"We [the committee] will show on our homepage, at the top the EU bank account, lower the AU bank account, and Paypal as a third option."

So, the code has to be rewritten again. Sorry, no testing needed at the moment.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1464 [Main CAcert Website] certificate issuing minor N/A 2019-08-04 16:54 2020-06-27 14:22
Reporter: Ted Platform:  
Assigned To: Ted OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Support ACME protocol for issuing certificates
Description: Request by CAcert board. First step is to evaluate the amount of work needed, then the decision should be made whether to implement the protocol or to postpone it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0005821)
Ted   
2019-08-04 17:00   
Start for research is Wikipedia https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment, the corresponding RFC seems to be https://tools.ietf.org/html/rfc8555
(0005822)
Ted   
2019-08-12 10:43   
I have given the RFC a first cursorry reading. My findings are recorded in the WiKi at https://wiki.cacert.org/Software/Projects/Bug%231464%3A%20ACME%20protocol

Feel free to add your own findings there.

As a (preliminary!) summary, I guess that there will be some work to do, implementing extensions to the CAcert website as well as implementing the protocol interface itself, probably several days of work, but that the job itself will not be impossible.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
775 [Main CAcert Website] certificate issuing minor have not tried 2009-09-05 10:25 2020-06-27 14:15
Reporter: Bas van den Dikkenberg Platform:  
Assigned To: egal OS:  
Priority: normal OS Version:  
Status: needs review Product Version: 2009 Q3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2015 Q1  
Reviewed by: Ted
Test Instructions:
Summary: A org ceritficate is only valild one year
Description: When i make an Organisational client certficate its only valid one year this must be two as far i can find in the policy. The policy doesn't specify that its not two year valid.

 
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0001476)
homer   
2009-09-06 12:12   
Hello Bas,

I guess you are right
http://www.cacert.org/index.php?id=19

Best regards,

Guillaume
(0001477)
homer   
2009-09-11 20:14   
Hello Bas,

I confirm the cert lifetime is one year what ever you choose codesigning or not (class 1 or 3 root).

Best regards,

Guillaume
(0001478)
homer   
2009-09-11 20:15   
confirmed Sept 11th 2009
(0002085)
Uli60   
2011-07-05 02:17   
(Last edited: 2011-07-05 11:49)
added note regarding certs issued under Organisation Assurance program are valid for 12 months under
https://wiki.cacert.org/FAQ/Privileges
redirection fix is handled under
https://bugs.cacert.org/view.php?id=897

to update the text, you have to update
https://wiki.cacert.org/FAQ/Privileges

http://www.cacert.org/policy/CertificationPracticeStatement.php
lists Organisation SubRoot -> Expiry of Certificates -> 24 months
for the new root and
Assured Members -> Expiry of Certificates -> 24 months
for the "old" root

http://www.cacert.org/policy/OrganisationAssurancePolicy.php
refers to CPS about cert issuing

affected source code is starting in:
https://cacert1.it-sls.de/account.php?id=16 (client certs)
https://cacert1.it-sls.de/account.php?id=20 (server certs)

probably one of the CommModule scripts needs to be reviewed
eg client.pl (sub calculateDays($)) l.440 ff. counts days based on received assurance points. if >= 50 then 730 days otherwise 180 days.
Does receive organisation users receive assurance points over 50 ?

client.pl l.835 (sub HandleCerts($$)) displays correct calculation:
      my $days=$org?($server?(365*2):365):calculateDays($row{"memid"});
if org (is yes), if server cert then calculate #days = 2 x 365 days = 730
sub calculateDays() will not be called here

(0004603)
INOPIAE   
2014-02-25 07:39   
I pushed a fix to https://github.com/INOPIAE/CAcert/tree/bug-775
(0005257)
BenBE   
2015-01-21 21:51   
Patch applied to testserver.

The testserver always uses 30 days instead of 730 days.
(0005260)
INOPIAE   
2015-01-21 22:24   
I just create a new org client cert. Duration is 2 years => ok
I just create a new org server cert. Duration is 2 years => ok
=>ok
(0005261)
Uli60   
2015-01-21 22:30   
renewed Org.Server cert => now valid for 2 years
renewed Org.Client cert => now valid for 2 years
(0005816)
Ted   
2019-07-17 07:42   
There has been an explicit request on the support mailing list for longer lasting org certificates, so I'm trying to revive this case...
(0005817)
Ted   
2019-07-21 21:15   
The changes checked in by INOPIAE in his commit 900a6f2b9ea899bcf66cbc47848d6a8057bcaca0
 five years ago are quite minimal.

I guess the easiest way to get it compatible to the current code is to manually re-do those changes on the current release branch...
(0005818)
Ted   
2019-07-21 21:25   
Note that Org-server certificates already are valid for 2 years on the production system, only client certs are reduced to 1 year validity...
(0005819)
Ted   
2019-07-21 21:57   
Hmm, indeed rebasing the existing bug-775 worked fine, so I pushed the branch to the GitHub-repository. git.cacert.org is not (yet) updated.
(0005820)
Ted   
2019-07-26 21:07   
bug-775 is now merged into test-1442 and installed on the (old) testserver, so it may once more be tested...
(0005823)
Golffies   
2019-08-22 15:20   
[Second attempt to submit the test report; previous drafted report got lost when submitting it, thanks to an "invalid authentication token" issue; some inaccuracies may have then been added to the present report, when re-writing it yet another time.]

Test report


1. Tested URL: https://test.cacert.org


2. Pre-requisites - Set #1:

2.1. having user's e-mail address been verified;
2.2. having been assured by other Assurers, up to 100 points;
2.3. being an Assurer, i.e having passed CATS;
2.4. being an Organisation Assurer.

All pre-requisites fulfilled by tuning existing user account registered on https://test.cacert.org through the Test Manager available at https://mgr.test.cacert.org:14843.


3. Pre-requisites - Set 0000002:

3.1. Having registered an Organisation;
3.2. Having defined yourself as an Administrator for that Organisation;
3.3. Having defined a Domain for that Organisation;

All prerequisites fulfilled by registering the related information on https://test.cacert.org.


4. Organisation Server Certificate - Steps which have been completed:

4.1. off-line preparing a CSR certificate with openssl;
4.2. requesting a new certificate under the Org Server Certs menu;
4.3. pasting the CSR in PEM format to the corresponding field;
4.4. choosing Class Root 1 as signing certificate;
4.5. choosing SHA512 as signature algorithm;
4.6. clicking on Submit button;
4.7. reviewing and confirming Organisation details on next screen;
4.8. getting a PEM on-screen copy of the Org Server generated certificate;
4.9. off-line reading the validity period of the certificate with openssl;
4.10. displaying the list of existing Server certificates under the Org Server Certs menu;
4.11. on-line reading the validity period of the considered certificate;
4.12. comparing the on-line (test.cacert.org) expiry dates with the off-line (openssl) expiry dates.

Results are given at the end of the report.


5. Organisation Client Certificate - steps completed:

5.1. off-line preparing a CSR certificate with openssl;
5.2. requesting a new certificate under the Org Client Certs menu;
5.3. entering required personal details;
5.4. keeping Class Root 3 (default) as signing certificate;
5.5. keeping SHA256 (default) as signature algorithm;
5.6. clicking on Next button;
5.7. pasting the same as previously CSR in PEM format to the corresponding field;
5.8. clicking on Submit CSR button;
5.9. getting a PEM on-screen copy of the Org Client generated certificate;
5.10. off-line reading the validity period of the certificate with openssl;
5.11. displaying the list of existing Client certificates under the Org Client Certs menu;
5.12. on-line reading the validity period of the considered certificate;
5.13. comparing the on-line (test.cacert.org) expiry dates with the off-line (openssl) expiry dates.

Results are given at the end of the report.


6. Observed results

6.1. Org Server Cert result to 0000004.9: [PASSED]

        Validity
            Not Before: Aug 22 09:54:00 2019 GMT
            Not After : Aug 21 09:54:00 2021 GMT

6.2. Org Server Cert result to 0000004.11: [PASSED]

        Expires
        2021-08-21 09:54:00

6.3. Org Server Cert result to 0000004.12: [PASSED]

        Not After : Aug 21 09:54:00 2021 GMT
        =
        2021-08-21 09:54:00


6.4 Org Client Cert result to 0000005.10: [PASSED]

        Validity
            Not Before: Aug 22 11:26:19 2019 GMT
            Not After : Aug 21 11:26:19 2021 GMT

6.5 Org Client Cert result to 0000005.12: [PASSED]

        Expires
        2021-08-21 11:26:19

6.6 Org Client Cert result to 0000005.13: [PASSED]

        Aug 21 11:26:19 2021 GMT
        =
        2021-08-21 11:26:19


7.1. Copy of the Org Server generated certificate:

7.1.1. Certificate in text format

$ openssl x509 -text -noout -in 2019-08-22_OrgaServCert.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 20697 (0x50d9)
    Signature Algorithm: sha512WithRSAEncryption
        Issuer: C=AU, ST=New South Wales, O=CAcert Testserver, OU=http://cacert1.it-sls.de, CN=CAcert Testserver Root
        Validity
            Not Before: Aug 22 09:54:00 2019 GMT
            Not After : Aug 21 09:54:00 2021 GMT
        Subject: C=FR, ST=Ile de France, L=Paris, O=Ellis BBS, CN=ellis.siteparc.fr
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:96:67:e1:d1:6a:69:05:c8:f5:ea:2f:a9:0d:7a:
                    21:f6:57:2d:24:15:aa:2f:2c:c5:85:79:fe:6f:5a:
                    9a:8c:e6:d4:65:2e:63:b5:ac:39:19:56:53:f9:4d:
                    56:56:80:db:91:5a:d6:de:9d:80:63:e1:00:20:e8:
                    9c:3c:07:5b:1d:67:31:76:f4:06:bb:74:78:d5:57:
                    0e:c9:3c:73:4c:0c:ac:32:8b:0b:8b:20:9b:d5:6e:
                    76:e9:cb:7d:df:5a:07:91:d2:aa:9b:da:59:62:87:
                    d2:b1:fb:f9:42:54:c0:4c:b5:53:5e:2a:85:5a:c2:
                    00:f7:d6:11:db:62:6c:b6:00:92:36:d0:0e:37:43:
                    87:48:04:9f:f9:80:c6:9b:37:e5:6c:6f:e9:c4:5a:
                    3a:1e:2e:be:8c:8d:2d:ad:e6:4c:35:e2:eb:87:e3:
                    b7:50:f5:2d:71:a3:ae:f6:36:7e:53:72:d9:aa:45:
                    0d:4e:eb:4e:cb:ee:c8:9c:19:f8:7f:e9:13:6b:54:
                    df:8f:8e:8b:57:51:a3:c7:26:24:e1:6f:90:dd:e8:
                    3a:f1:a9:01:25:a4:f4:05:3c:73:07:dd:3d:6f:b6:
                    ec:27:a2:f0:c8:27:7a:9a:96:e3:cc:35:1c:1a:df:
                    45:6b:fd:4b:27:05:b1:74:49:b4:b4:f4:43:db:2c:
                    e0:07
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication, Netscape Server Gated Crypto, Microsoft Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org/

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.cacert.org/revoke.crl

            X509v3 Subject Alternative Name:
                DNS:ellis.siteparc.fr, othername:<unsupported>
    Signature Algorithm: sha512WithRSAEncryption
         b2:e5:64:26:21:82:f0:1c:4d:87:3c:b3:fe:27:91:6d:8b:66:
         4a:a5:88:ca:65:20:29:14:38:82:ea:cf:e8:94:2f:77:00:4e:
         f5:cb:d7:9f:1b:b7:f1:a9:3b:f4:81:35:7a:05:87:9d:c5:05:
         97:04:a2:16:f6:08:aa:be:6b:4b:61:9b:c5:93:4e:d0:ca:f8:
         bd:95:ab:43:59:13:d9:ff:b3:89:b5:8c:e3:bb:11:20:82:e4:
         e7:c8:02:66:53:88:08:e2:33:9c:3b:52:f0:ec:2e:b2:a4:fc:
         7f:cf:9b:9e:28:8a:2c:41:1a:74:1a:ba:06:32:1f:42:0a:01:
         60:a4:08:7f:71:ec:e0:b3:9a:33:2f:3d:6d:93:2d:01:e5:65:
         b4:07:e8:f7:dc:8b:96:43:c4:ff:17:16:38:79:ca:00:d6:0b:
         99:01:f8:ea:29:e7:7c:e3:e1:42:eb:d5:e5:3e:fd:76:fa:6b:
         f3:f1:fb:08:ab:58:56:fa:4b:e8:dc:ec:64:eb:4e:2b:fc:e2:
         0b:a0:85:56:f9:07:02:a4:64:1e:25:35:c2:35:b4:9a:e1:77:
         77:6e:28:4f:ac:a5:c0:7d:89:a6:4f:0a:4f:3c:b0:ab:c1:a1:
         52:da:2b:26:c2:bb:a8:15:09:c9:97:06:03:d8:87:98:ca:25:
         e5:90:cf:86:73:0a:79:f0:98:12:40:18:be:8d:44:f1:c6:f4:
         7c:79:d3:b0:67:5d:20:a8:35:c3:52:81:83:12:e0:62:90:db:
         a4:19:e1:34:42:7e:ed:9b:7a:cb:91:94:e6:16:be:b6:15:28:
         0f:c8:72:cd:fa:1a:b4:df:82:d5:4e:55:8f:d2:78:69:de:b5:
         f1:5f:87:3d:b3:d7:db:aa:09:4d:c7:02:5a:18:ac:ae:d0:86:
         3e:e3:56:a1:b5:6e:0b:d9:62:9e:a4:8f:fd:c1:65:1b:db:3d:
         f6:2c:92:ed:30:13:8f:31:d8:c0:92:6f:a9:c9:5d:ee:ab:ff:
         f3:d1:39:f8:67:74:45:f4:a9:18:26:20:ce:25:ce:1f:b8:67:
         9c:67:b8:16:f3:b1:0e:b5:cf:8b:96:88:12:2d:4b:5c:6e:61:
         00:d3:67:34:2d:08:51:a2:3f:5a:18:fe:e9:e7:9c:e4:b9:0e:
         07:1f:cc:82:e3:79:d7:b5:8d:cf:5c:dc:2e:ee:f0:48:8e:8f:
         3c:1c:65:da:9f:76:85:19:2a:5c:20:2b:59:d5:6c:9b:68:8c:
         b5:e3:ac:a6:91:95:df:92:fa:bc:72:61:ce:5f:a9:7a:a2:6a:
         66:ee:07:03:2d:61:fe:9b:64:88:46:dc:bd:9d:07:7e:22:cf:
         e5:90:bf:60:68:d8:5f:55

7.1.2. Certificate in PEM format

-----BEGIN CERTIFICATE-----
MIIFaDCCA1CgAwIBAgICUNkwDQYJKoZIhvcNAQENBQAwgYcxCzAJBgNVBAYTAkFV
MRgwFgYDVQQIEw9OZXcgU291dGggV2FsZXMxGjAYBgNVBAoTEUNBY2VydCBUZXN0
c2VydmVyMSEwHwYDVQQLExhodHRwOi8vY2FjZXJ0MS5pdC1zbHMuZGUxHzAdBgNV
BAMTFkNBY2VydCBUZXN0c2VydmVyIFJvb3QwHhcNMTkwODIyMDk1NDAwWhcNMjEw
ODIxMDk1NDAwWjBlMQswCQYDVQQGEwJGUjEWMBQGA1UECAwNSWxlIGRlIEZyYW5j
ZTEOMAwGA1UEBwwFUGFyaXMxEjAQBgNVBAoMCUVsbGlzIEJCUzEaMBgGA1UEAwwR
ZWxsaXMuc2l0ZXBhcmMuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCWZ+HRamkFyPXqL6kNeiH2Vy0kFaovLMWFef5vWpqM5tRlLmO1rDkZVlP5TVZW
gNuRWtbenYBj4QAg6Jw8B1sdZzF29Aa7dHjVVw7JPHNMDKwyiwuLIJvVbnbpy33f
WgeR0qqb2llih9Kx+/lCVMBMtVNeKoVawgD31hHbYmy2AJI20A43Q4dIBJ/5gMab
N+Vsb+nEWjoeLr6MjS2t5kw14uuH47dQ9S1xo672Nn5TctmqRQ1O607L7sicGfh/
6RNrVN+PjotXUaPHJiThb5Dd6DrxqQElpPQFPHMH3T1vtuwnovDIJ3qaluPMNRwa
30Vr/UsnBbF0SbS09EPbLOAHAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADAOBgNV
HQ8BAf8EBAMCA6gwNAYDVR0lBC0wKwYIKwYBBQUHAwIGCCsGAQUFBwMBBglghkgB
hvhCBAEGCisGAQQBgjcKAwMwMwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzABhhdo
dHRwOi8vb2NzcC5jYWNlcnQub3JnLzAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8v
Y3JsLmNhY2VydC5vcmcvcmV2b2tlLmNybDA9BgNVHREENjA0ghFlbGxpcy5zaXRl
cGFyYy5mcqAfBggrBgEFBQcIBaATDBFlbGxpcy5zaXRlcGFyYy5mcjANBgkqhkiG
9w0BAQ0FAAOCAgEAsuVkJiGC8BxNhzyz/ieRbYtmSqWIymUgKRQ4gurP6JQvdwBO
9cvXnxu38ak79IE1egWHncUFlwSiFvYIqr5rS2GbxZNO0Mr4vZWrQ1kT2f+zibWM
47sRIILk58gCZlOICOIznDtS8OwusqT8f8+bniiKLEEadBq6BjIfQgoBYKQIf3Hs
4LOaMy89bZMtAeVltAfo99yLlkPE/xcWOHnKANYLmQH46innfOPhQuvV5T79dvpr
8/H7CKtYVvpL6NzsZOtOK/ziC6CFVvkHAqRkHiU1wjW0muF3d24oT6ylwH2Jpk8K
Tzywq8GhUtorJsK7qBUJyZcGA9iHmMol5ZDPhnMKefCYEkAYvo1E8cb0fHnTsGdd
IKg1w1KBgxLgYpDbpBnhNEJ+7Zt6y5GU5ha+thUoD8hyzfoatN+C1U5Vj9J4ad61
8V+HPbPX26oJTccCWhisrtCGPuNWobVuC9linqSP/cFlG9s99iyS7TATjzHYwJJv
qcld7qv/89E5+Gd0RfSpGCYgziXOH7hnnGe4FvOxDrXPi5aIEi1LXG5hANNnNC0I
UaI/Whj+6eec5LkOBx/MguN517WNz1zcLu7wSI6PPBxl2p92hRkqXCArWdVsm2iM
teOsppGV35L6vHJhzl+peqJqZu4HAy1h/ptkiEbcvZ0HfiLP5ZC/YGjYX1U=
-----END CERTIFICATE-----


7.2. Copy of the Org Client generated certificate:

7.2.1. Certificate in text format

$ openssl x509 -text -noout -in 2019-08-22_OrgaClientCert.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 23477 (0x5bb5)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=CAcert Testsever, OU=http://cacert1.it-sls.de, CN=CAcert Testserver Class 3
        Validity
            Not Before: Aug 22 11:26:19 2019 GMT
            Not After : Aug 21 11:26:19 2021 GMT
        Subject: C=FR, ST=Ile de France, L=Paris, O=Ellis BBS, OU=Gro\xC3\x9Fe Katastrophe, CN=John Doe (The Original!)/emailAddress=John.Doe@ellis.siteparc.fr
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:96:67:e1:d1:6a:69:05:c8:f5:ea:2f:a9:0d:7a:
                    21:f6:57:2d:24:15:aa:2f:2c:c5:85:79:fe:6f:5a:
                    9a:8c:e6:d4:65:2e:63:b5:ac:39:19:56:53:f9:4d:
                    56:56:80:db:91:5a:d6:de:9d:80:63:e1:00:20:e8:
                    9c:3c:07:5b:1d:67:31:76:f4:06:bb:74:78:d5:57:
                    0e:c9:3c:73:4c:0c:ac:32:8b:0b:8b:20:9b:d5:6e:
                    76:e9:cb:7d:df:5a:07:91:d2:aa:9b:da:59:62:87:
                    d2:b1:fb:f9:42:54:c0:4c:b5:53:5e:2a:85:5a:c2:
                    00:f7:d6:11:db:62:6c:b6:00:92:36:d0:0e:37:43:
                    87:48:04:9f:f9:80:c6:9b:37:e5:6c:6f:e9:c4:5a:
                    3a:1e:2e:be:8c:8d:2d:ad:e6:4c:35:e2:eb:87:e3:
                    b7:50:f5:2d:71:a3:ae:f6:36:7e:53:72:d9:aa:45:
                    0d:4e:eb:4e:cb:ee:c8:9c:19:f8:7f:e9:13:6b:54:
                    df:8f:8e:8b:57:51:a3:c7:26:24:e1:6f:90:dd:e8:
                    3a:f1:a9:01:25:a4:f4:05:3c:73:07:dd:3d:6f:b6:
                    ec:27:a2:f0:c8:27:7a:9a:96:e3:cc:35:1c:1a:df:
                    45:6b:fd:4b:27:05:b1:74:49:b4:b4:f4:43:db:2c:
                    e0:07
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            Netscape Comment:
                To get your own certificate for FREE head over to http://www.CAcert.org
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                E-mail Protection, TLS Web Client Authentication, Microsoft Encrypted File System, Microsoft Server Gated Crypto, Netscape Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.cacert.org

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://test.cacert.org/test-class3-revoke.crl

            X509v3 Subject Alternative Name:
                email:John.Doe@ellis.siteparc.fr
    Signature Algorithm: sha256WithRSAEncryption
         c0:11:7f:12:84:96:65:b3:70:cc:6c:5b:c6:ca:9a:18:07:d6:
         1e:c5:58:34:46:0d:1d:e9:7d:40:40:a4:65:cf:51:17:d3:ec:
         8f:fa:a3:3c:d2:8b:69:d3:26:cb:4a:7e:a9:13:6c:67:b4:70:
         54:86:55:f8:20:08:49:47:db:2b:ba:f3:9a:aa:a2:0b:60:eb:
         b0:f2:70:70:c6:a5:4c:e4:ce:f0:db:77:48:8f:e5:3c:b4:7d:
         90:60:18:cd:41:d3:74:07:1b:1e:33:e8:bb:cd:2d:c9:5a:4a:
         8c:4a:61:3d:9c:c0:ea:6e:e4:9b:95:04:05:97:c0:40:96:3e:
         43:5b:ca:c5:2a:21:59:6f:79:22:d0:14:b0:72:97:30:56:07:
         3f:26:59:06:98:b4:cf:91:0b:38:b5:ea:26:a7:9b:a2:35:65:
         71:6b:38:c6:6d:54:59:44:bd:9a:71:a4:c0:64:c9:70:78:0e:
         2b:61:07:82:19:68:e9:46:70:fd:4e:73:78:0c:6c:9b:3e:2a:
         cb:d1:55:65:08:c9:b7:d5:d9:53:54:d1:af:d1:56:12:3c:eb:
         e6:b5:ad:e3:7b:0e:f6:10:1e:b6:e4:98:bf:46:9c:40:48:6f:
         b4:cb:c7:b2:9b:9b:2f:06:3d:0a:14:21:35:c5:88:73:75:52:
         a9:3d:ab:00:8a:6d:2d:d5:88:3c:01:2f:e6:33:5a:2a:db:c8:
         59:5e:02:e1:e7:3d:17:1a:0f:e3:54:eb:86:24:29:f5:fa:5c:
         c0:f0:e1:45:2f:78:62:0e:41:da:ca:e9:fd:b7:a3:92:78:0b:
         6a:0a:00:17:e9:d9:16:18:3f:d8:2e:71:cf:e8:62:e2:98:74:
         ab:90:be:7a:d3:2e:0c:f8:a0:05:72:9c:20:1a:da:2d:ed:4b:
         23:9c:2a:5f:4f:93:d8:5e:f2:0c:49:dc:ac:05:a8:5c:72:8d:
         c8:64:92:20:f1:87:4a:c4:93:ab:4d:e7:f3:f9:32:1d:75:e2:
         56:28:4e:62:8b:b7:e3:f2:49:09:c2:85:b8:37:2e:74:68:53:
         0d:35:0e:97:59:f5:cb:1d:e8:4b:87:0c:9a:f2:42:e2:86:18:
         27:dc:1e:7e:d9:80:63:7d:77:a7:2e:96:f7:f7:de:70:64:a0:
         5b:fc:e3:52:0a:7d:4a:af:2e:ad:21:b6:e1:a8:63:ad:89:50:
         cb:38:c4:d8:f2:c8:1e:79:ce:23:57:a9:85:56:f8:32:bb:04:
         b1:18:3f:61:3d:06:3d:c8:11:c2:26:d7:c6:89:f2:75:8a:b1:
         f6:e2:27:e6:64:be:50:44:2b:b1:b2:5f:19:56:ab:f4:8f:78:
         05:11:f4:c2:32:02:57:ac

7.2.2. Certificate in PEM format

-----BEGIN CERTIFICATE-----
MIIF7DCCA9SgAwIBAgICW7UwDQYJKoZIhvcNAQELBQAwYjEZMBcGA1UEChMQQ0Fj
ZXJ0IFRlc3RzZXZlcjEhMB8GA1UECxMYaHR0cDovL2NhY2VydDEuaXQtc2xzLmRl
MSIwIAYDVQQDExlDQWNlcnQgVGVzdHNlcnZlciBDbGFzcyAzMB4XDTE5MDgyMjEx
MjYxOVoXDTIxMDgyMTExMjYxOVowgbQxCzAJBgNVBAYTAkZSMRYwFAYDVQQIDA1J
bGUgZGUgRnJhbmNlMQ4wDAYDVQQHDAVQYXJpczESMBAGA1UECgwJRWxsaXMgQkJT
MRswGQYDVQQLDBJHcm/Dn2UgS2F0YXN0cm9waGUxITAfBgNVBAMMGEpvaG4gRG9l
IChUaGUgT3JpZ2luYWwhKTEpMCcGCSqGSIb3DQEJARYaSm9obi5Eb2VAZWxsaXMu
c2l0ZXBhcmMuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCWZ+HR
amkFyPXqL6kNeiH2Vy0kFaovLMWFef5vWpqM5tRlLmO1rDkZVlP5TVZWgNuRWtbe
nYBj4QAg6Jw8B1sdZzF29Aa7dHjVVw7JPHNMDKwyiwuLIJvVbnbpy33fWgeR0qqb
2llih9Kx+/lCVMBMtVNeKoVawgD31hHbYmy2AJI20A43Q4dIBJ/5gMabN+Vsb+nE
WjoeLr6MjS2t5kw14uuH47dQ9S1xo672Nn5TctmqRQ1O607L7sicGfh/6RNrVN+P
jotXUaPHJiThb5Dd6DrxqQElpPQFPHMH3T1vtuwnovDIJ3qaluPMNRwa30Vr/Usn
BbF0SbS09EPbLOAHAgMBAAGjggFXMIIBUzAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG
+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVh
ZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gw
QAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEE
AYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo
dHRwOi8vb2NzcC5jYWNlcnQub3JnMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly90
ZXN0LmNhY2VydC5vcmcvdGVzdC1jbGFzczMtcmV2b2tlLmNybDAlBgNVHREEHjAc
gRpKb2huLkRvZUBlbGxpcy5zaXRlcGFyYy5mcjANBgkqhkiG9w0BAQsFAAOCAgEA
wBF/EoSWZbNwzGxbxsqaGAfWHsVYNEYNHel9QECkZc9RF9Psj/qjPNKLadMmy0p+
qRNsZ7RwVIZV+CAISUfbK7rzmqqiC2DrsPJwcMalTOTO8Nt3SI/lPLR9kGAYzUHT
dAcbHjPou80tyVpKjEphPZzA6m7km5UEBZfAQJY+Q1vKxSohWW95ItAUsHKXMFYH
PyZZBpi0z5ELOLXqJqebojVlcWs4xm1UWUS9mnGkwGTJcHgOK2EHghlo6UZw/U5z
eAxsmz4qy9FVZQjJt9XZU1TRr9FWEjzr5rWt43sO9hAetuSYv0acQEhvtMvHspub
LwY9ChQhNcWIc3VSqT2rAIptLdWIPAEv5jNaKtvIWV4C4ec9FxoP41TrhiQp9fpc
wPDhRS94Yg5B2srp/bejkngLagoAF+nZFhg/2C5xz+hi4ph0q5C+etMuDPigBXKc
IBraLe1LI5wqX0+T2F7yDEncrAWoXHKNyGSSIPGHSsSTq03n8/kyHXXiVihOYou3
4/JJCcKFuDcudGhTDTUOl1n1yx3oS4cMmvJC4oYYJ9weftmAY313py6W9/fecGSg
W/zjUgp9Sq8urSG24ahjrYlQyzjE2PLIHnnOI1ephVb4MrsEsRg/YT0GPcgRwibX
xonydYqx9uIn5mS+UEQrsbJfGVar9I94BRH0wjICV6w=
-----END CERTIFICATE-----


8. Side note

Is it a OK for our application to let an Organisation Administrator to make use of the same private key / CSR, for generating both an Org Server Cert and an Org Client Cert?
(0005825)
Ted   
2019-08-23 18:42   
> 8. Side note
>
> Is it a OK for our application to let an Organisation Administrator to make use of the same private key / CSR,
> for generating both an Org Server Cert and an Org Client Cert?

IMHO it does not make much sense to use the same key for different types of certificates (client/server), but it should not pose a problem for CAcert. Though I did not do elaborate evaluations I don't see how this feature can be abused.

Of course it is extremly bad practice to use the same key for different certificates, regardless if they are of the same or of the different type.
The only (more or less) sensible use of a key in multiple certificates is when a certificate is renewed, when the certificate has the same relevant content (CN) and only differs in formal fields (expiration date and similar). I personally would advise against even this practice.
(0005826)
Ted   
2019-08-23 18:44   
This issue now needs to be reviewed. I'll do one review myself and hope Dirk will do the other one. Or is there any other Software Assessor out there?
(0005827)
Ted   
2019-08-23 18:52   
Reviewed commit ad77a681eda40a7a0331adffaf67bfb16986adac versus d328ebd6ad641a9caf4c80208a14d3b8f768edc0

The changes are very minimal, the review is PASSED


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1241 [Main CAcert Website] misc major always 2014-01-27 12:41 2020-06-27 12:18
Reporter: hanno Platform:  
Assigned To: jandd OS:  
Priority: high OS Version:  
Status: solved? Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: cacert.org SSL/TLS configuration is bad on many levels
Description: I just had a look how the cacert.org webpage performs in its SSL/TLS-Settings. See the Qualys SSL test:
https://www.ssllabs.com/ssltest/analyze.html?d=cacert.org

It's very bad. Issues that should be adressed:
* It doesn't support TLS 1.1 and TLS 1.2. There have been various issues with older TLS versions due to the crappy way it combines CBC and MAC, so everyone these days recommends to support TLS 1.2 with GCM.
* It uses RC4 and MD5 as it's first cipher. RC4 should be avoided and MD5 has been extremely broken for a very very long time.
* It doesn't ship the class3 as a certificate chain, so people importing the cacert root in their browser will still not see the page cert as valid.
* Only very limited support for Perfect Forward Secrecy.
* DH key exchange with 1024 bit only.

I can give more details and explanations for each of those issues if needed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: CAcert-SSLLabsreport-20141018.pdf (111,978 bytes) 2014-10-18 10:50
https://bugs.cacert.org/file_download.php?file_id=385&type=bug
CAcert-SSLLabsreport-20141201.pdf (113,642 bytes) 2014-12-01 15:22
https://bugs.cacert.org/file_download.php?file_id=393&type=bug
Notes
(0004626)
NEOatNHNG   
2014-03-10 18:09   
Cipher suite configuration should probably changed to something like

# CAcert cipher suite configuration
SSLHonorCipherOrder on
SSLCipherSuite kEECDH:kEDH:AESGCM:ALL:+3DES!RC4:!LOW:!EXP:!MD5:!aNULL:!eNULL


That doesn't solve the TLS 1.1/1.2 issue, that needs a system upgrade.

The class3 certificate is not needed in the chain because the certificate is directly signed by the root.

DH keys with more than 1024 bit are only available in Apache >=2.4.7. Otherwise we would need to patch it ourselves and I wouldn't go down that road right now. That's why in the above cipher spec ECDH is preferred over DH because there the EC key size offers more security than 1024 bit DH. Once Apache 2.4.7 is deployed we should probably switch those because of some uncertainties in EC.
(0004635)
NEOatNHNG   
2014-03-11 23:08   
New cipher suite configuration was deployed. More ciphers will be available after system update.
(0004885)
hanno   
2014-07-13 12:32   
I'm surprised that this has been closed as most issues I mentioned are not fixed at all.

Also, it seems currently the webpage is vulnerable to the CCS injection bug. (it is not THAT severe, because the known attacks only affect newer openssl-versions, but still Adam Langley pointed out that there are likely other attacks without that limitation).
(0004990)
sebix   
2014-09-07 14:10   
cats.cacert.org has an F-rating: https://www.ssllabs.com/ssltest/analyze.html?d=cats.cacert.org And uses an outdated OpenSSL-Version from prior to June 2014 (nearly 3 full months ago!), as it's affected by CVE-2014-0224. It includes ciphers like RC2, RC4, DES, DES40.
secure.cacert.org and ocsp.cacert.org only provide up to TLS1.0: https://www.ssllabs.com/ssltest/analyze.html?d=secure.cacert.org https://www.ssllabs.com/ssltest/analyze.html?d=ocsp.cacert.org
infrastructure.cacert.org uses a cert for monitor.cacert.org
finance.cacert.org uses a cert from board.cacert.org

For state-of-the-art crypto in TLS I recommend using 'Applied Crypto Hardening' by https://bettercrypto.org

CaCert is a showcase project on how crypto should be done and represents an important part of the Web of trust. On the other hand it uses vulnerable and weak crypto on some subdomains.
(0004991)
wytze   
2014-09-07 14:39   
Please note that this bug primarily concerns www.cacert.org and secure.cacert.org. For these services, we are waiting on the approval of a fairly trivial application bug fix, after which we can re-do the upgrade of the chroot OS environment to Debian Wheezy -- including *much* better openssl support, which will make a considerable rating difference. Still, even without that upgrade, the current SSL Labs rating of these services is "B" when we disregard the trust issue -- an issue, which can only be resolved by getting the CAcert root certificate included in major browser distributions.

For ocsp.cacert.org, SSL is fairly unimportant: we are receiving ZERO real OCSP requests over SSL (https). The https channel is only used by a few sites trying to establish the security of the site it seems (140 reqs in one full month ...). Still, the "B" rating (again disregarding the trust issue) is fairly decent. We can probably improve it by upgrading the OS to a more recent version.

cats.cacert.org is another category: this system is not managed by the critical system admin team. Please file a separate bug for this system, so the problem can be assigned to the appropriate sysadmin. At first look, it would seem that a simple reconfig of the Apache webserver there would make a major difference. You could also e-mail cats-admin@cacert.org directly.
(0004992)
sebix   
2014-09-07 15:24   
Thanks for the response and the explanations, so this issue currently blocked by 0001260.
For cats.cacert.org I filed a separate issue, referencing this one.
(0004993)
wytze   
2014-09-07 15:41   
This issue is specifically blocked by https://bugs.cacert.org/view.php?id=1301.
https://bugs.cacert.org/view.php?id=1260 has a much wider scope, we don't have to wait for a full fix of that one to address the current issue.
(0005056)
wytze   
2014-10-18 10:49   
By upgrading the CAcert chroot application environment to Debian Wheezy on October 17, 2014 (see https://lists.cacert.org/wws/arc/cacert-systemlog/2014-10/msg00007.html), the SSL support of the cacert.org main webserver has been brought up-to-date. While there is still scope for improvement (e.g. dropping SSLv3 protocol support, dropping 3DES cipher support), the issues raised in this bug entry appear to have been resolved. I will add a note with the current report from www.ssllabs.com for www.cacert.org.
(0005057)
wytze   
2014-10-18 10:52   
Check the attached file https://bugs.cacert.org/file_download.php?file_id=385&type=bug for the SSLLabs report for www.cacert.org on October 18, 2014.
(0005059)
hanno   
2014-10-19 15:24   
This issue has now been closed the second time without being fixed. It's getting ridiculous.

Unfixed and mentioned in the original report:
* DH key exchange with insecure length

Other issues:
* No ocsp stapling
* SSLv3 is enabled. If you haven't heard it: SSLv3 is insecure. Completely. This wasn't such a big issue when this bug was opened, but we know better now (POODLE attack 4 days ago)
(0005060)
wytze   
2014-10-19 16:04   
I did not close the issue, but only reported a significant fix, setting status to "solved?" (note the question mark). Another evaluation would have to take place before the issue could be closed. Evidently it cannot be closed yet.

As for the issues mentioned:
* DH key exchange with insecure length
- DH key length was indeed not addressed by the reported fix.
  Increasing the key length is desirable of course, but currently we are limited
  by the options of the deployed software: Debian Stable (Wheezy) with Apache2
  2.2.22. This will have to wait until Debian Jessy gets promoted to Stable.
* No OCSP stapling
- Not mentioned in the original issue. I agree that OCSP stapling is a nice
  feature to have, but again we are limited by Debian/Apache. OCSP stapling is
  supported from Apache 2.3.3 onwards I think, so again Debian Jessy will be
  fine.
* SSLv3 is enabled
- Yes, it is and will remain so for another while because we are visited by
  clients with MSIE 6.0, which we must support. But we are planning to phase
  them out. In the meantime, we can recommend everyone to use a contemporary
  browser to visit www.cacert.org; such browsers will support TLS_FALLBACK_SCSV,
  which we also support at the server side, so they are protected against
  unintended protocol downgrades.
(0005061)
wytze   
2014-10-20 13:22   
The SSLv3 issue has been split off in a separate issue:
   https://bugs.cacert.org/view.php?id=1303
(0005139)
wytze   
2014-12-01 15:22   
On December 1, 2014, support for SSL3 and 3DES has been disabled on the CAcert webserver, and HSTS has been enabled for additional security hardening.
Check for details https://lists.cacert.org/wws/arc/cacert-systemlog/2014-12/msg00000.html

Other options mentioned by the reporter of this issue:
- DH key length
- OCSP Stapling
are still waiting for the Debian project promoting Jessy to stable.
(0005140)
wytze   
2014-12-01 15:23   
Check the attached file https://bugs.cacert.org/file_download.php?file_id=393&type=bug for the SSLLabs report for www.cacert.org on December 1, 2014.
(0005171)
sebix   
2014-12-14 10:47   
If I haven't overseen something, this issue has been successfully solved for most sites.
However, lists.cacert.org still supports SSL3 (but all TLS versions up to 1.2) and anonymous ciphers, and the cipher preference could be better. See https://www.ssllabs.com/ssltest/analyze.html?d=lists.cacert.org for more details.
(0005174)
Mathias   
2014-12-14 13:36   
Hi!

To summarize things, I checked the situation on the following hosts that I know:

- blog.cacert.org: seems OK
- board.cacert.org: NOT OK, see 0001349
- bugs.cacert.org: seems OK
- cats.cacert.org: seems OK
- email.cacert.org: NOT OK, see 0001350 (HTTPS), 0001351 (SMTP via STARTTLS) - sorry for using the same subject (copy&paste error)
- git.cacert.org: seems OK
- irc.cacert.org: NOT OK, see 0001346
- issue.cacert.org: seems OK
- lists.cacert.org: NOT OK, see 0001347 (HTTPS), 0001352 (SMTP via STARTTLS)
- secure.cacert.org: seems OK
- svn.cacert.org: NOT OK, see 0001348
- translations.cacert.org: NOT OK, see 0001353
- wiki.cacert.org: seems OK
- www.cacert.org: seems OK

Are there any hosts missing?

I think it's too early for the "all clear" signal...

If there's a possibility to help in further examining *and* fixing these issues, please give me a hint.

Regards
Mathias
(0005749)
wytze   
2019-01-24 11:36   
Reassigning this to jandd because the only issue blocking closing this one is 0001350, which is assigned to jandd.
(0005889)
jandd   
2020-06-27 12:18   
issues with email certificates have been resolved


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1350 [Main CAcert Website] misc major always 2014-12-14 12:38 2020-06-27 12:17
Reporter: Mathias Platform:  
Assigned To: jandd OS:  
Priority: urgent OS Version:  
Status: solved? Product Version: 2014 Q4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2014 Q4  
Reviewed by:
Test Instructions:
Summary: {community,email}.cacert.org SSL/TLS configuration rated grade F on SSL Labs
Description: Hi!

SSL/TLS issues on {community,email}.cacert.org (roundcube via HTTPS):
- anonymous cipher suites enabled
- SSLv3 enabled (POODLE attack)
- no TLS v1.1
- no TLS v1.2
- TLS compression enabled (CRIME attack)
- no secure renegotiation (RFC 5746)
- no forward secrecy with reference browser provided

For short: very extremely bad :-(

Please see
https://lists.cacert.org/wws/arc/cacert-sysadm/2014-12/msg00000.html

Thanks for looking into this issue.

Mathias
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: SSL_Labs-email.cacert.org-grade_F-20141214.pdf (169,102 bytes) 2014-12-14 12:38
https://bugs.cacert.org/file_download.php?file_id=398&type=bug
SSL_Labs-email.cacert.org-grade_B-20150125.pdf (100,750 bytes) 2015-01-25 17:42
https://bugs.cacert.org/file_download.php?file_id=405&type=bug
Notes
(0005209)
jandd   
2014-12-27 11:52   
did the best to improve the configuration but the possibilities are very limited because the community webmail system is still on Apache 2.2.3/Debian Etch and does not support modern TLS versions or cipher suites.

At least we get a grade B at ssllabs now.
(0005268)
Mathias   
2015-01-25 17:53   
Debian 4.0 Etch had received official support until 15 Feb 2010 - which is nearly five years ago! Hm, if this system isn't actually used/maintained by anybody, there might be someone to press the "big red button" for it...
(0005269)
Mathias   
2015-01-25 18:10   
I just saw on https://wiki.cacert.org/SystemAdministration/Systems/Email that pressing the "red button" is not a good idea.

From a today's point of view the SSL/TLS configuration is still not satisfying. But the main cause and source of problems (also the ones of this bug) is the VERY OLD system. So, I leave this bug open with stomach pains :-)

However, thanks, Jan, for digging so deep in this issue.
(0005888)
jandd   
2020-06-27 12:17   
email, webmail and community get a grade A (ignoring trust issues) now. https has been tested with the ssllabs test, smtp and imap have been tested using https://github.com/drwetter/testssl.sh


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1162 [Main CAcert Website] source code tweak have not tried 2013-04-17 08:15 2020-05-22 11:33
Reporter: Uli60 Platform:  
Assigned To: INOPIAE OS:  
Priority: high OS Version:  
Status: fix available Product Version: 2013 Q2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: calcutate (the passwords) hash in php instead of in mysql -> \\
Description: subtitle: Increase in password problems after production environment upgrade (2013-04-03)

Support and Critical team received reports via several channels (email, irc) that people with special chars in their passwords had problems in logging on, recovering their passwords

Question to critical team about current state of "magic quotes" setting after migration is all OFF
magic quotes setting before migration was ON

The "magic quotes" feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0

The support of "magic quotes" probably also relates to other then passwords storage functions in the webdb code
I'll remember about a problem we had back in 2009 with multipled backslashes in comments fields. PG did some magical on the production system and fixed this problem (this was, before software assessment team started working)

global task: mimicry the "magic quotes" function in all php code in transfer data to and from mysql database
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0003905)
INOPIAE   
2013-04-22 20:35   
some hints taken from ticket s20130415.71
38 charcters
upper and lower case, numbers and these special characters <>:+-?@$&\#
did not work

25 charcters
upper and lower case, numbers and these special characters :$/{[),
did work
(0003908)
INOPIAE   
2013-04-23 20:17   
some hints from the next ticket s20130422.77
@ seems to make problems
(0003913)
INOPIAE   
2013-04-23 20:56   
pushed the fix with the exchange from mysql_escape_string to mysql_real_escape_string
https://github.com/INOPIAE/CAcert/commit/f0318d79dbc69e444fee4c085cdb3ee152318e1c
(0004047)
BenBE   
2013-06-11 21:10   
On Testserver
(0004375)
Eva   
2013-10-08 22:13   
(Last edited: 2013-10-08 22:14)
Changed Password to
a1<>:+-?@$&\#
and to
""1234567890123sflkjasf$/{[),äöüµ@€ßÆïЖÇѢĕ§;:|° ^~‘`´\/
and to
যেমন কিছু我的名字是 اسمي如東西таких как нечто
(bengal, easy chineese, space, arabic, classic chineese, russian)

Both were accepted and did not produce problems at the login afterwards.

Then I set the password as Admin again to
1234567890123sflkjasf$/{[),äöüµ@€ßÆïЖÇѢĕ§;:|° ^~‘`´\/

I could login without problems afterwards.

[However when I tried to reset my password to something quite easy I got an error because it was too short, but neither in the error message nor in the interface for resetting passwords I was informed how long a password has to be. (As SE I could set such a short PW.)]

=> ok

(0004399)
JensK   
2013-10-20 13:44   
(Last edited: 2013-10-20 13:46)
1. Changed password (as user) to:
a1<>:+-?@$&\#
""1234567890123sflkjasf$/{[),äöüµ@€ßÆïЖÇѢĕ§;:|° ^~‘`´\/
যেমন কিছু我的名字是 اسمي如東西таких как нечто
GP10xwzI5i

Login worked in all cases => OK

2. Set another user's password (as admin) to the same passwords as above

Login worked in all cases => OK

(0004456)
NEOatNHNG   
2013-11-19 15:19   
The proposed fix only replaces mysql_escape_string() by mysql_real_escape_string(). It does nothing to calculate the password hash in PHP instead of MySQL

=> Rejected
(0005491)
GuKKDevel   
2015-12-11 10:08   
(Last edited: 2015-12-11 14:58)
Tried to solve the problem with:

https://github.com/CAcertOrg/cacert-devel/commit/2cb06760223218ca4b2a0482225d6fbfa77a63bb

and

https://github.com/CAcertOrg/cacert-devel/commit/a7eaa6d8e14ba7152e3ed3d200b30ad1eed68610

But didn't test, because I don't have a Testsystem so far.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
755 [CATS.cacert.org] Content (Questions and Answers) major always 2009-07-13 20:23 2020-05-22 11:33
Reporter: duff Platform:  
Assigned To: Ted OS:  
Priority: normal OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 'back'-button shows solution of test
Description: After failing the cats once and trying it again, you can view the results of the new test when you use the back button of your browser to get back to the results page of the previous test. instead of showing the old results, the page content is updated with the new questions.

steps to reproduce: start new test, answer all questions (ie randomly) and evaluate. then start a new test and use the back button (open it in a new tab) of the browser to view the results.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: cat-cacert_bug.png (36,856 bytes) 2012-12-31 01:46
https://bugs.cacert.org/file_download.php?file_id=308&type=bug
Notes
(0001462)
octo   
2009-07-26 14:32   
When pressing the “Back” button to get back to the results page, I was asked if I wanted to re-send the POST data. I accepted without thinking much and got presented a results page with 100% correct answers. The system (the main page, too) now shows two tries, the second of which with perfect scores.

I didn't try to reproduce for obvious reasons, but I think the required steps to be:
* Take test, submit
* Wait for results page
* Follow an arbitrary link
* Press “Back” button
* Accept to re-send POST data

(Sorry should the formatting screw up, there is no preview option..)
(0001910)
Uli60   
2011-04-06 09:09   
(Last edited: 2011-04-06 09:10)
jcurl from 0000919
While I passed my first test with 88%, I was trying to figure out if there was a way to print the results (the comments given, even if correct) are useful (so I further clicked on some other pages). To get back to the results page, I jumped back some pages (sorry, I don't recall to what exact URL).
 
What happened, the page was empty (i.e. no questions) and told me I had reached 100%.

This is now recorded as having done the tests twice, whereby I've only done it once. Results confirmed by logging into secure.cacert.org and also cats.cacert.org, whereby I see the system believes I really did two tests.

(0002681)
baarn   
2011-11-08 19:43   
confirming this.
did the test once and failed, did it again and succeded. the other three results are from browsing backwards and forward in the browser. as you can see one test "failed" horribly, but the other two suceeded with 100%

#-- first two are actual tests
pos date number of questions correct
1 2011-11-08 19:08:01 25 72 %
2 2011-11-08 19:28:34 25 92 %
#-- below here are fake tests
3 2011-11-08 19:29:30 25 100 %
4 2011-11-08 19:29:50 25 32 %
5 2011-11-08 19:29:57 25 100 %
(0003583)
AlainV   
2012-12-31 01:54   
(Last edited: 2012-12-31 01:56)
Confirming how to become an insurer in only 2mn 39":
please see attachement: cat-cacert_bug.png [^] (36,856 bytes) 2012-12-31 01:46
Test 100% granted: only clic back, back, back, back... just after completed a previous test.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
611 [CATS.cacert.org] User Interface feature always 2008-09-13 04:28 2020-05-22 11:32
Reporter: jandd Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: use gettext for translations
Description: instead of using dozens of constants in lang/*.php it would be a good idea to use the proven GNU gettext interface for translation.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0001164)
jandd   
2008-09-13 04:32   
This would require work for


     
  • putting marked text snippets into the existing php code

  •  
  • automatic extraction of .pot files (i.e. via make + xgettext)

  •  
  • merge of semi-complete .po files (i.e via make + msgmerge)

  •  
  • compilation of .mo files from .po files

  •  
  • proper initialization of the gettext system at runtime

(0005520)
jandd   
2016-05-03 18:23   
created cats project in pootle http://translations.cacert.org/projects/cats/


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1431 [Main CAcert Website] GPG/PGP crash always 2018-02-19 09:10 2020-05-22 11:32
Reporter: wytze Platform: Main CAcert Website  
Assigned To: GuKKDevel OS: N/A  
Priority: urgent OS Version: stable  
Status: needs review & testing Product Version: 2017 Q4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2017 Q4  
Reviewed by:
Test Instructions:
Summary: GPG/PGP signing request is not properly checked for images
Description: A GPG/PGP signing request submitted to CAcert should not contain an image (as stated on the submission page). However, the code which validates and massages the signing request, does not properly check for this. As a result, it is possible to (accidentally or deliberately) create a very large signing request, by including a large image. Such requests will cause the communication between the web frontend and the signer machine to fail, and *all* certificate signing is blocked from that moment on.
Tags: GPG
Steps To Reproduce: I have not attempted to reproduce the problem, but there is historic evidence present on the production servers. Look for gpg requests 23644, 23645 or 23656 (they are identical). The first one caused a blockade of all CAcert signing from Fridat 16.02.2018 23:01 until Sunday 18.02.2018 16:00, when the problem was recognised and "remedied" by moving the signing request to the side. This particular signing request contained an image of 955207 bytes.
Additional Information: Due to the nature of this problem, any CAcert user with sufficient points to submit a GPG signing request, is able to block all signing operations. Therefore this bug will be set to private until a solution can be implemented.

In my view there are two problems to be solved here:
1. GPG signing requests with images should be rejected or filtered (probably not very difficult).
2. The communcation process between web frontend and signer should be resistent against huge requests: either handle them correctly, or reject them beforehand (probably difficult).
If issue #1 is solved, the priority for solving issue 0000002 can be lowered.
System Description Production version of the CAcert website
Attached Files:
Notes
(0005577)
GuKKDevel   
2018-03-05 14:32   
https://github.com/CAcertOrg/cacert-devel/pull/4/commits/67062a789285c7096e976a7ae7543a569bfc8678


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1443 [Infrastructure] documentation feature N/A 2018-10-26 20:59 2020-05-22 11:32
Reporter: jandd Platform: Default  
Assigned To: jandd OS: any  
Priority: normal OS Version: any  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: write a specification of what the current code in https://git.cacert.org/gitweb/?p=cacert.git does
Description: There is no proper documentation of the existing code base. This documentation is needed to:

- write a proper specification for a potential rewrite
- implement unit tests
- understand the code base which is especially important for anybody wanting to help
Tags:
Steps To Reproduce:
Additional Information: Documentation should be in a version controlled repository. Human readable (HTML) exports should be generated and published automatically. (See infradocs.cacert.org/jenkins.cacert.org for an example how to do this).
System Description Default profile.
Attached Files:
Notes
(0005616)
jandd   
2018-10-26 22:30   
I started a new repository at https://git.cacert.org/gitweb/?p=cacert-codedocs.git and setup a Jenkins job https://jenkins.cacert.org/job/cacert-codedocs/ that is triggered by pushes to the master branch of that repository. Pushes to this repository via git+ssh protocol are allowed to members of the git-doc group on git.cacert.org.
(0005617)
jandd   
2018-10-26 23:53   
I setup codedocs.cacert.org publishing on Jenkins and Apache VirtualHost configuration on web.cacert.org and webstatic.cacert.org. https://infradocs.cacert.org/ has been updated. I requested a DNS CNAME for codedocs.cacert.org to make the generated documentation available at https://codedocs.cacert.org/ I'll update the Jenkins job description when the CNAME has been setup.
(0005620)
jandd   
2018-10-29 21:27   
The code documentation repository is now mirrored to https://github.com/CAcertOrg/cacert-codedocs to encourage contributions.
(0005646)
GuKKDevel   
2018-11-03 14:09   
I'll try to get the whole www-directory documented.
(0005652)
GuKKDevel   
2018-11-04 13:13   
Is there a way to build a cross-reference-list?
So one can see which file uses which file and is used by which file?
(0005653)
jandd   
2018-11-04 18:24   
It is possible to use the .. index: macros for cross references but I think it would be better to have something more code centric. I'll see if I find some free time to implement something like the IP address list, ssh key list or certificate list build for infradocs.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1445 [Main CAcert Website] General minor always 2018-11-04 04:41 2020-05-22 11:32
Reporter: pmoulding@cacert.org Platform: Test CAcert Website  
Assigned To: OS: N/A  
Priority: normal OS Version: Test  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: The code has cacert.org hardcoded. Replace with settings file.
Description: There are 2846 instances of cacert.org in the code. Some are comments and some are constants that should be moved to a configuration file.
Some are straight text and should be something like the following in a .ini file.
domain_name = cacert.org
Some are capitalised and should be something like the following in a .ini file.
domain_name_display = CAScert.org
Some are email addresses and could be something like the following in a .ini file.
lists_email_address = cacert-tverify@lists{domain_name}

In the config file, domain name would be first then substituted into the following settings.
Tags:
Steps To Reproduce: Perform a global scan for cacert.org. You will see lines like the following.
$body .= "CAcert.org user\n\n";
Additional Information: This could be added to some common code used for other things including an autoloader. I would not hold up the mysql or other issues for this change.
System Description Test version of the CAcert website
Attached Files:
Notes
(0005651)
jandd   
2018-11-04 09:08   
this is not an infrastructure (system administration) issue. It does not belong into this bug tracker project but into the main website project.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1450 [Main CAcert Website] source code tweak always 2018-11-11 19:12 2020-05-22 11:31
Reporter: bdmc Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Modify sendmail function in CAcert to include test functionality
Description: Ensure that the source code for the web site uses only a mail function that is contained within the web site source code.

This mail function will use configuration variables to control whether it is in Test or Production mode, as well as other options.
Tags:
Steps To Reproduce:
Additional Information: This change requires the Configuration File change described in Bug 1449.
Attached Files:
Notes
(0005662)
bdmc   
2018-11-11 20:21   
(Last edited: 2018-11-14 03:43)
At present, the only modification to the sendmail() function is to test for a Production State being either Production or Test. If it is Test, then the destination e-mail address is modified to a pre-determined ( configuration variable ) value.

That modification removes the existing To address from the sendmail() call, and replaces it with an address found in the configuration file.

(0005669)
GuKKDevel   
2018-11-14 14:09   
did you look up if/where on the test server is a mechanism to reroute emails to test-mgr?

for testing purpose it is not useful to send all mails to a predefined email-address, because in this case only one person can test at a time. or if sending to a list, all members of that list would get the messages too.
(0005670)
jandd   
2018-11-14 15:09   
test.cacert.org has a postfix configuration that intercepts all outgoing mails and stores them in a single mailbox that is made available to testmgr via dovecot/IMAP.
(0005671)
bdmc   
2018-11-14 17:56   
I am informed that the Test Server has special e-mail configuration that can override this change, so am cancelling it.
(0005674)
Ted   
2018-11-15 20:09   
I agree that this issue is not relevant for bug-1260, and not important for any other issue I'm aware of. There are lots of more important issues open for the "core" developers.

But it may be a nice warmup excercise for a new developer to provide some possible variants of the sendmail function, so people who want to install their own testserver have some options if they don't want (or are not able to) configure their mailer as it currently is on the testserver.

So, maybe we keep this issue open with a low priority, just in case someone new is looking for a job?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1432 [Main CAcert Website] source code feature have not tried 2018-03-11 11:19 2020-05-22 11:31
Reporter: GuKKDevel Platform:  
Assigned To: GuKKDevel OS:  
Priority: normal OS Version:  
Status: needs feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: since september, 8th, 2017 CAs must check DNS' CAA records
Description: Dear Board,

since september, 8th, 2017 CAs must check DNS' CAA records. This decision was taken in spring 2017 by CA/Browser forum which CAcert is member of.

I can't see that this is already implemented in CAcert's signing software, therefore I would like to ask you to take care of.

.....
BR, Alex.
Tags: browser, certificates, domain, server certificates
Steps To Reproduce:
Additional Information: https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum

German:
https://www.golem.de/news/tls-zertifikate-zertifizierungsstellen-muessen-caa-records-pruefen-1709-129981.html
Attached Files:
Notes
(0005579)
GuKKDevel   
2018-03-19 13:42   
Solution wont work on WINDOWS Server as
Parameter DNS_CAA is not defined at any Windows Server (date 2018-03-18) needed for PHP-function 'dns_get_record'
 * https://bugs.php.net/bug.php?id=75909
(0005580)
GuKKDevel   
2018-04-05 14:01   
Mail from Benedict to Etienne:
<snip>
CAcert cannot be recorded as a full CA at the CABF, since it is not
according to WebTrust or ETSI 319 411. The CABF activities therefore only
affect CAcert if they will voluntarily submit to it. Working at CABF is
currently neither useful nor advisable due to the number of resources
available in CAcert.
<snip>
(0005633)
GuKKDevel   
2018-11-01 12:12   
mail-correspondence:
https://lists.cacert.org/wws/arc/cacert-policy/2018-03/msg00000.html
https://lists.cacert.org/wws/arc/cacert-policy/2018-03/msg00001.html
https://lists.cacert.org/wws/arc/cacert-policy/2018-03/msg00002.html


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1254 [Main CAcert Website] website content major always 2014-03-02 16:17 2020-05-22 11:30
Reporter: BenBE Platform:  
Assigned To: BenBE OS:  
Priority: high OS Version:  
Status: fix available Product Version: 2014 Q1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2014 Q2  
Reviewed by:
Test Instructions:
Summary: Update the signed PGP-Message containing the fingerprints of CAcert
Description: Raised by a message on the mailing list there is little apriori information that enables someone distrusting the CAcert class 1 root to verify its integrity and authenticity with the information provided in the root certificate download section (index/3).

Given you can trace a trust path from your OpenPGP key to the one used to sign the message with the information you should be able to fully verify the information on that page. Unfortunately the current signature only covers the MD5 and SHA1 hash of the certificate - which both constitute weak hashes in todays standards.

Thus it'd be nice to have the GnuPG signature be updated to include a much broader set of hashes. See below for more details.
Tags:
Steps To Reproduce: Try to verify the CAcert Class 1 Root certificate and CAcert Class 3 Intermediate certificate only by trusting the information in the block on index/3 while distrusting MD5 entirely and assuming SHA1 to be unreliable.
Additional Information: A better informational block captured in the signature might look like:

---
Fingerprints for the CAcert Class 1 Root certificate:
=====================================================

for a in md4 md5 sha1 ripemd160 sha224 sha256 sha384 sha512 whirlpool; do \
openssl x509 -noout -fingerprint -$a -in class1.pem ; done

MD4 Fingerprint=
    EB:36:C3:01:E3:AC:CE:CE:D1:C1:DF:A5:D8:17:BC:50
MD5 Fingerprint=
    A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B
SHA1 Fingerprint=
    13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
RIPEMD160 Fingerprint=
    EA:B7:2F:F1:24:04:4B:57:D4:45:BE:97:E7:3B:CD:92:C2:6D:AE:1D
SHA224 Fingerprint=
    60:1D:E5:E5:56:C9:91:B6:BD:A6:75:43:FB:5C
    73:71:BD:E1:27:FF:A6:84:24:2F:66:F3:16:88
SHA256 Fingerprint=
    FF:2A:65:CF:F1:14:9C:74:30:10:1E:0F:65:A0:7E:C1
    91:83:A3:B6:33:EF:4A:65:10:89:0D:AD:18:31:6B:3A
SHA384 Fingerprint=
    DF:63:0B:17:89:70:CF:75:B1:E2:4E:F0:DD:7B:F5:24
    B6:9D:64:80:6E:D1:EC:07:BF:D5:F7:AB:32:DE:96:51
    9D:46:CC:CA:D3:B3:E3:89:40:6E:7B:A8:2B:55:B4:B6
SHA512 Fingerprint=
    EB:0A:D8:4F:11:B4:B0:8B:F7:6C:78:66:EF:32:84:22
    92:BB:B2:86:2F:B6:FC:49:C0:A3:F8:07:62:9C:A8:F5
    DD:28:A0:DE:7B:0C:04:D5:66:02:0A:C4:FF:2B:A4:4E
    2F:61:2A:A5:8A:1A:E4:CC:AC:E4:86:D2:44:95:2F:C2
whirlpool Fingerprint=
    64:9E:AB:97:59:10:EF:E0:DD:78:D2:A8:B4:B1:D1:6B
    A4:08:39:42:50:F0:1A:A8:6E:38:B4:4A:52:2B:35:75
    ED:98:4A:C9:53:77:BD:DA:E2:18:41:8C:BD:21:41:1A
    EC:53:E2:08:FF:21:31:A2:B2:CF:F3:FB:81:79:AF:D7

Fingerprints for the CAcert Class 3 Intermediate certificate:
=============================================================

for a in md4 md5 sha1 ripemd160 sha224 sha256 sha384 sha512 whirlpool; do \
openssl x509 -noout -fingerprint -$a -in class3.pem ; done

MD4 Fingerprint=
    60:B7:CD:A2:F2:18:55:3F:1B:F0:43:31:A4:06:82:9C
MD5 Fingerprint=
    F7:25:12:82:4E:67:B5:D0:8D:92:B7:7C:0B:86:7A:42
SHA1 Fingerprint=
    AD:7C:3F:64:FC:44:39:FE:F4:E9:0B:E8:F4:7C:6C:FA:8A:AD:FD:CE
RIPEMD160 Fingerprint=
    41:A5:08:B6:C7:35:54:58:0E:F6:EE:C1:86:FA:A3:6D:BF:E9:D5:E1
SHA224 Fingerprint=
    90:C6:94:5B:4B:91:D3:72:49:BD:CD:D2:A4:51
    CC:24:A6:E0:8A:1D:ED:1E:E3:C4:53:7C:17:21
SHA256 Fingerprint=
    4E:DD:E9:E5:5C:A4:53:B3:88:88:7C:AA:25:D5:C5:C5
    BC:CF:28:91:D7:3B:87:49:58:08:29:3D:5F:AC:83:C8
SHA384 Fingerprint=
    DF:92:B7:83:6F:2A:CD:A0:07:9A:0B:14:7C:C8:D5:92
    20:E7:6C:76:61:9A:75:3C:0B:64:D1:3F:13:E3:A5:CB
    C6:81:92:0A:86:62:A0:95:44:03:DE:10:AB:72:1D:B1
SHA512 Fingerprint=
    3C:6E:24:87:E4:9F:43:06:15:E4:E5:7C:9D:8D:67:5F
    36:41:FC:00:3F:7D:95:26:DD:BC:AA:35:DA:6D:5D:B4
    B1:59:03:47:62:BA:BA:4C:29:98:60:42:96:EC:C3:11
    5F:AB:81:2F:04:F0:E4:D4:B2:EE:C6:9C:B3:B8:3B:F1
whirlpool Fingerprint=
    78:64:5C:D2:20:2A:DB:CC:54:3D:26:38:71:E7:17:15
    66:A0:88:47:E3:E2:26:31:B4:CD:63:7B:B1:D2:53:AC
    EE:0B:19:2A:0C:4F:82:6B:AB:8B:14:0F:09:9D:99:BD
    3B:9E:5D:E8:A6:CA:6D:3D:B6:33:08:52:AA:5F:C4:46

Fingerprints for the CAcert OpenPGP signing key:
================================================

LC_ALL=C gpg --list-key --fingerprint gpg@cacert.org

pub 1024D/65D0FD58 2003-07-11 [expires: 2033-07-03]
      Key fingerprint = A31D 4F81 EF4E BD07 B456 FA04 D2BB 0D01 65D0 FD58
uid CA Cert Signing Authority (Root CA) <gpg@cacert.org>
sub 2048g/113ED0F2 2003-07-11 [expires: 2033-07-03]
---

This also gives instructions on how to obtain the information presented in the signature block and thus helping people verify this data.
Attached Files: fix1254.sh (2,813 bytes) 2014-11-13 16:09
https://bugs.cacert.org/file_download.php?file_id=389&type=bug
fix1254-signer.sh (2,793 bytes) 2014-11-13 16:13
https://bugs.cacert.org/file_download.php?file_id=390&type=bug
files-1254.tar.gz (2,657 bytes) 2014-11-13 16:13
https://bugs.cacert.org/file_download.php?file_id=391&type=bug
files_for_certs_folder.zip (2,257 bytes) 2014-11-21 10:38
https://bugs.cacert.org/file_download.php?file_id=392&type=bug
Notes
(0004614)
dominiks   
2014-03-02 21:52   
Actually, the simplest to use (from GPG user perspective) seems to me to sign
the complete key (root.crt, root.der, root.txt) and supply the detached
signature. It is the usual procedure and then you need only GnuPG for
verifying and don't have to verify the hashes, find the bloody openssl syntax
and then compare again manually the hashes.
(0004705)
BenBE   
2014-04-09 21:59   
(Last edited: 2014-04-09 22:02)
Updated version shortened to only include SHA1, SHA-256, SHA-512 and Whirlpool for better compatibility to the average user:

---
Fingerprints for the CAcert Class 1 Root certificate:
=====================================================

for a in sha1 sha256 sha512 whirlpool; do \
openssl x509 -noout -fingerprint -$a -in class1.pem ; done

SHA1 Fingerprint=
    13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
SHA256 Fingerprint=
    FF:2A:65:CF:F1:14:9C:74:30:10:1E:0F:65:A0:7E:C1
    91:83:A3:B6:33:EF:4A:65:10:89:0D:AD:18:31:6B:3A
SHA512 Fingerprint=
    EB:0A:D8:4F:11:B4:B0:8B:F7:6C:78:66:EF:32:84:22
    92:BB:B2:86:2F:B6:FC:49:C0:A3:F8:07:62:9C:A8:F5
    DD:28:A0:DE:7B:0C:04:D5:66:02:0A:C4:FF:2B:A4:4E
    2F:61:2A:A5:8A:1A:E4:CC:AC:E4:86:D2:44:95:2F:C2
whirlpool Fingerprint=
    64:9E:AB:97:59:10:EF:E0:DD:78:D2:A8:B4:B1:D1:6B
    A4:08:39:42:50:F0:1A:A8:6E:38:B4:4A:52:2B:35:75
    ED:98:4A:C9:53:77:BD:DA:E2:18:41:8C:BD:21:41:1A
    EC:53:E2:08:FF:21:31:A2:B2:CF:F3:FB:81:79:AF:D7

Fingerprints for the CAcert Class 3 Intermediate certificate:
=============================================================

for a in sha1 sha256 sha512 whirlpool; do \
openssl x509 -noout -fingerprint -$a -in class3.pem ; done

SHA1 Fingerprint=
    AD:7C:3F:64:FC:44:39:FE:F4:E9:0B:E8:F4:7C:6C:FA:8A:AD:FD:CE
SHA256 Fingerprint=
    4E:DD:E9:E5:5C:A4:53:B3:88:88:7C:AA:25:D5:C5:C5
    BC:CF:28:91:D7:3B:87:49:58:08:29:3D:5F:AC:83:C8
SHA512 Fingerprint=
    3C:6E:24:87:E4:9F:43:06:15:E4:E5:7C:9D:8D:67:5F
    36:41:FC:00:3F:7D:95:26:DD:BC:AA:35:DA:6D:5D:B4
    B1:59:03:47:62:BA:BA:4C:29:98:60:42:96:EC:C3:11
    5F:AB:81:2F:04:F0:E4:D4:B2:EE:C6:9C:B3:B8:3B:F1
whirlpool Fingerprint=
    78:64:5C:D2:20:2A:DB:CC:54:3D:26:38:71:E7:17:15
    66:A0:88:47:E3:E2:26:31:B4:CD:63:7B:B1:D2:53:AC
    EE:0B:19:2A:0C:4F:82:6B:AB:8B:14:0F:09:9D:99:BD
    3B:9E:5D:E8:A6:CA:6D:3D:B6:33:08:52:AA:5F:C4:46

Fingerprints for the CAcert OpenPGP signing key:
================================================

LC_ALL=C gpg --list-key --fingerprint gpg@cacert.org

pub 1024D/65D0FD58 2003-07-11 [expires: 2033-07-03]
      Key fingerprint = A31D 4F81 EF4E BD07 B456 FA04 D2BB 0D01 65D0 FD58
uid CA Cert Signing Authority (Root CA) <gpg@cacert.org>
sub 2048g/113ED0F2 2003-07-11 [expires: 2033-07-03]
---

@dominiks: Detached signatures for the downloadable files are a ice idea but are impractical in some situations when encoding/line endings differ or other issues on the client side arise for verification. Furthermore does a detached signature only provide one validation - with this somewhat longer text you have different test vectors so you desire to test them or one turns out unreliable.

(0005104)
wytze   
2014-11-13 16:08   
A script has been written which can be used on the signing server to collect all the signatures requested for this issue. The script is attached.
(0005105)
wytze   
2014-11-13 16:13   
On November 12, 2014, the fix1254.sh script has been executed on the signing server. Unfortunately, it turned out that the openssl version in use on the signing server is too old to support the 'whirlpool' digest. Hence the script has been edited to omit the generation of 'whirlpool' fingerprints in the documents to be signed.
The modified script has been attached as fix1254-signer.sh.
The produced signature files have been attached as a compressed tar file named files-1254.tar.gz.
(0005115)
INOPIAE   
2014-11-21 10:41   
(Last edited: 2014-11-21 10:44)
I pushed the fix to https://github.com/INOPIAE/CAcert/commit/c4e1fb4b3d1c155f27679c69728d61918cbb4eeb.
As I had trouble with the automatic CrLf correction I attached the files for the certs folder in files_for_certs_folder.zip
I renamed the file fingerprint-long-complex.txt.asc to cacert-pki-fingerprints.txt.asc



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1451 [Main CAcert Website] certificate issuing minor have not tried 2018-11-18 10:01 2020-05-12 18:27
Reporter: Ted Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: mail addresses
Description:








Reported by dastrath, but translated by me:

"Support regularly received mails from IANA that a mail has been sent to 192.168.x.x. Every time this happens an IANA ticket is created, which is then closed after a few days."

First of all there should be some research if it is possible to provoke mails to be sent to RFC1918 mail addresses on the testsystem. Maybe this can happen during registration of a new account, or by trying to add an IP-address as a domain.

IP addresses should not be accepted as domains at all. I'm quite sure that this is already handled, but I did not test. So, use your imagination and try to get the testsystem to accept (or at least, send a probe mail to) an IP address!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1397 [webstatic] General feature always 2015-08-19 21:50 2020-03-05 08:53
Reporter: MartinGummi Platform:  
Assigned To: BenBE OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: evaluate gitolite3
Description: Debian 8 (jessie) ships gitolite3[1] as successor of gitolite(2.x)

Please Test gitolite3 and migration of the current repositorys

[1] https://packages.debian.org/jessie/gitolite3
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0005863)
marthasimons   
2020-03-05 08:53   
Test


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1477 [Main CAcert Website] website content minor always 2020-02-11 13:07 2020-02-11 13:07
Reporter: L10N Platform: all  
Assigned To: OS: all  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: swag.cacert.eu is no more available
Description: As the cacert.eu domain is now redirected to cacert.org, the subdomain swag.cacert.eu is no more available. The issue is, that in the time we distributed or sold coffee cups with a QR quode linking to that sub domain.

I have no idea about the content of this sub domain, as at the internet archive the site is not recorded, but at least it should be redirected to a running service.
Tags: domain, down, merchandising
Steps To Reproduce: Take a cacert.org coffee cup:
https://twitter.com/CAcert/status/1158448103650930690/photo/1

Follow the QR code.
It goes to swag.cacert.eu

At swag.cacert.eu is an error message: Site could not be found. (Seite konnte nicht gefunden werden)
If I change to cacert.eu it is redirected to cacert.org
Additional Information: As this cups are still somewhere, it would be nice to fix or redirect it.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1447 [Main CAcert Website] block always 2018-11-06 11:26 2020-01-23 10:20
Reporter: pgmillon Platform: Main CAcert Website  
Assigned To: OS: N/A  
Priority: urgent OS Version: stable  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Cannot access main cacert website
Description: Using Firefox 63.0 on Manjaro Linux 18.0 (Kernel Linux 4.14.78-1-MANJARO) I can't access https://www.cacert.org/ website at all to fetch/update my certificates.

Error code is SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED
Tags:
Steps To Reproduce:
Additional Information:
System Description Production version of the CAcert website
Attached Files: screenshot.png (35,880 bytes) 2018-11-06 11:26
https://bugs.cacert.org/file_download.php?file_id=446&type=bug
Notes
(0005726)
L10N   
2019-01-03 13:17   
What happens, when you "Add Exception…"?
Can you add an exception?
(0005727)
pgmillon   
2019-01-03 13:30   
Hi,
No I can't add an exception.
(0005728)
pgmillon   
2019-01-03 13:31   
I looks like a combo: algorithm disabled and can't add exception because of HSTS.
(0005729)
L10N   
2019-01-03 13:42   
Have you already tried to replace the root certificate, as described here:
https://wiki.cacert.org/FAQ#New_Root_Certificates
(0005789)
pgmillon   
2019-04-04 09:52   
Re-importing the root certificate within Firefox solved the problem
https://wiki.cacert.org/FAQ?action=AttachFile&do=view&target=CAcert_chain_X0F_X0E.pem
(0005859)
alkas   
2020-01-14 15:00   
Chains, roots, bundles moved to https://wiki.cacert.org/FAQ/NewRoots
after 20190410
(0005860)
h_hucke   
2020-01-23 08:40   
I can't access the main site "https://www.cacert.org/" from germany. "No Route to host". "wiki.cacert.org" which is just a few steps away is accessable. Possibly "bit.nl" has anti DDOS meshures in place?
(0005861)
egal   
2020-01-23 10:20   
There had been an issue on the server which hosts www.cacert.org.

It required a full power-down-cycle to get it running again (after we tried to reboot the server via software yesterday).

Some more details can be found at blog.cacert.org, a deeper root-cause-analysis will be done later the day and published there.

(Small note: This issue has nothing to do with certificate issues on www.cacert.org.)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1475 [Main CAcert Website] minor always 2020-01-14 15:20 2020-01-14 15:20
Reporter: alkas Platform: Main CAcert Website  
Assigned To: OS: Linux  
Priority: normal OS Version: n/a  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions: Linux; see description
Summary: cacert.org DNSSEC contains links to both old and the new roots
Description: If you use the "host -t TXT _url.root.g1._fp.cacert.org." command referring the old root, you'll get the link "http://www.cacert.org/certs/root.crt"; if you use the "host -t TXT _url.root_X0F.g1._fp.cacert.org." command, you'll get the link "http://www.cacert.org/certs/root_X0F.crt".
Possibly the link is forged from the command.(?)
Both the links are valid, e.g. you can download the old root or the new one.
Tags:
Steps To Reproduce: Linux, see description
Additional Information:
System Description Production version of the CAcert website
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1471 [CATS.cacert.org] User Interface major always 2019-10-17 09:51 2019-10-28 21:59
Reporter: koutras_g@yahoo.com Platform: Default  
Assigned To: Ted OS: any  
Priority: high OS Version: any  
Status: needs feedback Product Version: production  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: https://cats.cacert.org Page error
Description: When I try to access the cats page I get the below error both on Firefox and Chrome (in incognito mode too).

Secure Connection Failed

An error occurred during a connection to cats.cacert.org. PR_END_OF_FILE_ERROR

Thanks,
George
Tags:
Steps To Reproduce: 1. Start the web browser
2. Go to: https://cats.cacert.org
Additional Information:
System Description Default profile.
Attached Files: 2019-10-17_11h50_58.png (29,787 bytes) 2019-10-17 09:51
https://bugs.cacert.org/file_download.php?file_id=469&type=bug
Notes
(0005855)
Ted   
2019-10-28 21:59   
Hmm, cats.cacert.org requests a client certificate when you try to connect. If you don't have a client certificate installed it may well be that this is the resulting error. Not really helpful, but sadly that's rather common in this area...

So, do you have a client certificate installed?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1468 [Infrastructure] general major always 2019-09-26 09:32 2019-09-26 10:39
Reporter: drtjstone Platform: Main CAcert Website  
Assigned To: egal OS: N/A  
Priority: normal OS Version: stable  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Getting SSL_ERROR_HANDSHAKE_FAILURE_ALERT on Firefox and other certificate problems
Description: See attached screenshot from logging into main site.
Tags: browser, server certificates
Steps To Reproduce: Logging into the main site or https://cats.cacert.org/
Additional Information:
System Description Production version of the CAcert website
Attached Files: Screenshot 2019-09-26 at 10.20.09.pdf (290,916 bytes) 2019-09-26 09:32
https://bugs.cacert.org/file_download.php?file_id=468&type=bug
Notes
(0005844)
jandd   
2019-09-26 10:28   
@dirk could you check the certificate chain for the blog container's Apache httpd? Maybe it still has the old intermediate/class3 and root/class1 certificates.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1467 [Main CAcert Website] certificate issuing major always 2019-09-19 19:54 2019-09-20 17:46
Reporter: tim.devries Platform: Default  
Assigned To: OS: any  
Priority: urgent OS Version: any  
Status: new Product Version: 2015 Q3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Code signing cert access not showing within website.
Description: Background: I have 100 points from several years ago. I’ve filled out the request to get it enabled. No response.

Is anyone needed to look after this? I can devote time to it.
Tags:
Steps To Reproduce: Login under my username/password.
Additional Information: Please email for credentials to confirm, if allowed/necessary.
System Description Default profile.
Attached Files:
Notes
(0005838)
Ted   
2019-09-20 17:46   
Part of the current problem is that support is seriously understaffed.

Sadly this cannot be easily remedied, since support staff members need some additional requesites (a background check), which takes several months to complete if enough Arbitrators are available to do the job.

I'll try to push your application by personal contact, but cannot promise anything...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1427 [Main CAcert Website] certificate issuing major always 2017-06-19 22:05 2019-09-10 21:33
Reporter: ntiemare0 Platform: Main CAcert Website  
Assigned To: OS: N/A  
Priority: normal OS Version: stable  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Unable to obtain certificate through API/CCSR.php
Description: I have been trying to automate the issuing of my CA certs, using the api found at cacert.org/api/ccsr.php

I'm creating the CSR and requesting the cert through PHP and Curl, passing the information though post. but, instead of returning the certificate, it responds with "404,Your certificate request has failed. ID:" and when i check my CA listing page, it lists a "pending" cert with no serial.

I've double and triple checked everything, but can't seem to get it to work.
Tags: api Client Certs
Steps To Reproduce: following the parameters at https://wiki.cacert.org/Software/CertApi, submit an HTTP request for a CA Cert. see attached file for used php code.
Additional Information:
System Description Production version of the CAcert website
Attached Files: auto_cert.php (1,438 bytes) 2017-06-19 22:05
https://bugs.cacert.org/file_download.php?file_id=420&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1460 [Main CAcert Website] account administration minor always 2019-02-27 21:00 2019-02-28 10:36
Reporter: Ted Platform:  
Assigned To: Ted OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Show mailserver error when creating new account
Description: When creating a new account, and the check of the mail address fails because of the mailserver not accepting the address. currently only "Failed to make a connection to the mail server" is shown as error message.

Showing the reason why the mailserver rejected the address would help in support to give some advise to the potential new member.

Until 0001288 the error line of the mailserver was shown if the check failed in the last "RCPT TO..." step. The commit 86c04b83870dc547fdcef25f91b1bc3b1de53619, which effectively removed the message, looks like this may have been accidentially due to copy/paste procedures.

The easiest solution of this issue would be to remove the lines 624 to 627 in the commit above. But when tackling this issue, maybe the error reporting could be improved in more situations...
Tags:
Steps To Reproduce: Try to create an account for an existing domain, not non existing account. Thesystem reports "Failed to make a connection to the mail server" but should mention something like "550 Requested action not taken: mailbox unavailable".
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1457 [bugs.cacert.org] misc minor always 2019-01-27 14:46 2019-02-25 22:07
Reporter: Ted Platform:  
Assigned To: egal OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Please increase session timeout on bugs.cacert.org
Description: Hi, could the session timeout on bugs.cacert.org be increased? It looks like it is currently something around 15 or maybe 30 minutes.

It is very frustrating when I try to write a comment, looking up some things to make sure I don't tell bullshit, just to have to start all over again because of a session timeout message.

I'd ask for an absolute minimum of 1 hour for the timeout, but preferable it should be 4 or even 8 hours.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0005756)
jandd   
2019-01-27 15:52   
Hello Dirk, I do not know Mantis well enough to help here. Do you know how to increase the session timeout?
(0005759)
wytze   
2019-01-30 07:58   
This is an annoyance indeed. What happens to me fairly often is that I open a particular bug page in my browser, leave it there for a couple of hours while looking into the actual problem (and possibly get distracted by other stuff), then return to the open page and add a comment -- which fails due to the timeout, and all data entered is lost :-(
Even with a much longer timeout one might run into this trap, the safest solution is to refresh the page in the browser before entering new data. But it's easy to forget ...
(0005762)
egal   
2019-02-01 15:38   
I just changed the timeout-variable for mantis from 5 minutes to 30 minutes. Please verify, if the timeout is now extended ... we should then find a consens between security and comfortability ...
(0005773)
Ted   
2019-02-14 22:26   
Test, last action was 22:50
(0005779)
Ted   
2019-02-25 22:07   
I just found out that the default refresh time seems to be set to 30 minutes. So, maybe setting the timeout to 35 minutes will prevent most of the incomfortabilities? At least I just set my refresh timeout to 10 minutes, so I should already be on the safe side... :-)

BTW, what is the attack scenario which is prevented by a short timeout? It's hard to judge "security" without knowing what may happen...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1459 [Main CAcert Website] my account major always 2019-02-22 11:37 2019-02-25 21:33
Reporter: wytze Platform: Default  
Assigned To: GuKKDevel OS: any  
Priority: immediate OS Version: any  
Status: fix available Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: e-mail verification fails for many addresses since upgrade from PHP 5.5 to PHP 5.6
Description: e-mail verification fails for many e-mail addresses since the upgrade of PHP 5.5 to PHP 5.6 on the CAcert main webserver.
This is due to the fact that PHP 5.6 has introduced a new parameter for setting up TLS/SSL connections, verify_peer_name, which is set to TRUE by default:

http://php.net/manual/en/context.ssl.php#refsect1-context.ssl-changelog says

5.6.0 Added peer_fingerprint and verify_peer_name. verify_peer default changed to TRUE.

As a result, any mail address which is served by a mail server which has been setup with a certificate whose CN does not match the MX name, will fail the checkEmail() validation in www/includes/general.php. The error message logged on the server (but not shown to the user :-() is (mailserver.domain.name and mx.domain.name are hypothetical names here):

PHP Warning: stream_socket_enable_crypto(): Peer certificate CN=`mailserver.domain.name' did not match expected CN=`mx.domain.name'

While such a mail server setup is not 100% clean, it is very common, especially with hosters hosting many different domains, and CAcert users should be able to get their e-mails verified for such domains (like they were in the past, when PHP 5.5 was still deployed).
Tags:
Steps To Reproduce:
Additional Information: The following code fix solves this problem:

--- general.php.org 2019-02-14 09:17:44.753793847 +0100
+++ general.php 2019-02-22 12:35:20.403100537 +0100
@@ -593,6 +593,7 @@
                                $fp_opt = array(
                                        'ssl' => array(
                                                'verify_peer' => false, // Opportunistic Encryption
+ 'verify_peer_name' => false, // Opportunistic Encryption
                                                )
                                        );
                                $fp_ctx = stream_context_create($fp_opt);
System Description Default profile.
Attached Files:
Notes
(0005774)
wytze   
2019-02-22 11:39   
(Last edited: 2019-02-22 11:42)
Due to the severity of this problem, which affects many domains as proven by a quick scan of the error logs for this specific message, the code fix listed in the Additional Information section has been deployed immediately on the production server as an emergency patch. Testing is therefore only possible on the test1.cacert.org server.

(0005775)
wytze   
2019-02-22 16:21   
Retrospective log analysis of the production server reveals that this failure has occurred 9580 times, between Apr 16 16:08:39 2018 and Feb 22 11:46:52 2019. Hence an emergency patch seems justified here.
(0005776)
wytze   
2019-02-22 16:23   
For proper testing on test.cacert.org, the checkEmailDummy function needs to be eradicated!
(0005777)
Ted   
2019-02-25 21:31   
Created new branch bug-1459 with Wytze's changes and pushed it to github and git.cacert.org.

Created new test branch test-1459 with enabled mail checking and checked it out on test.cacert.org. Note that Wytze's changes are not yet merged in, so it is now possible to to tests with the old version of mail checking.
(0005778)
Ted   
2019-02-25 21:33   
Reviewed the change. It is PASSED because there is no policy stating that SSL certificates of mail servers are checked strictly. Usually we even accept unencrypted mailserver connections...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1456 [Main CAcert Website] organisational section minor always 2019-01-22 21:39 2019-02-14 21:35
Reporter: L10N Platform: Default  
Assigned To: GuKKDevel OS: any  
Priority: high OS Version: any  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: COAP web form is broken
Description: When I try to finish "https://wiki.cacert.org/CoapHTML" by using the
button "Submit the form: generate PDF file", I receive an error message:
"pdf.cacert.eu" could not be found.
The URL, that doesn #t work:
https://pdf.cacert.eucacertpdf.php?name=Patent-+und+Rechtsanwaltskanzlei+..."
What can I do to make it working?
Tags: coap, organisation assurance, Wiki
Steps To Reproduce: 1. open the web form at "https://wiki.cacert.org/CoapHTML"
2. fill in the information
3. click on "Submit the form: generate PDF file"
4. Error message "pdf.cacert.eu" could not be found
Additional Information: information came by user T.R. trought the webform
System Description Default profile.
Attached Files: access.log (3,092 bytes) 2019-02-01 15:49
https://bugs.cacert.org/file_download.php?file_id=464&type=bug
error.log (503,093 bytes) 2019-02-01 15:49
https://bugs.cacert.org/file_download.php?file_id=465&type=bug
Notes
(0005742)
L10N   
2019-01-22 21:40   
This bug has some importance, as the committee likes to push OrgA (organisation assurance).
(0005743)
L10N   
2019-01-22 21:45   
I contacted the owner of cacert.eu. For some time, there was a new website, but today, the URL is redireted to cacert.org. He does not know, where pdf.cacert.eu was pointed. Maybe it was something new with Java?

(Original messages in German:
    pdf.cacert.eu -> war das nicht "dein" neuer Server?
    Wenn ich www.cacert.eu aufrufe, ist die neue Seite weg und ich werde auf
    org umgeleitet. Weisst du, ws mit pdf. passiert ist?

Nope ... Nur die Domain ist meine ...
Ich weiß aber auch nicht mehr, wo PDF.c.eu bin zeigte ... :-(
Es kann durchaus sein, dass das auf eine neue Umgebung gegangen ist, die schon mit Java (?) Lief ...
Aber ... Das generieren der CAP bzw COAP sollte auch in der alten Umgebung möglich sein ...
(0005744)
L10N   
2019-01-22 21:45   
I tested what happens, if I change the URL from pdf.cacert.eu to pdf.cacert.org It did not match neither.
(0005745)
L10N   
2019-01-22 21:48   
Next step, I had a look to the changes that happened to wiki.caccert.org/CoapHTML (at "info") and saw, that the .eu address was added in 2013 by inopiae. So I created a test content form at wiki.cacert.org/CoapHTML and then, at the error page, I replaced in the URL "pdf.cacert.eu/cacertpdf.php" with "www.cacert.org/coapnew.php" (remaining everything before and after as it was) and reloaded the page again.

Half success: it created a complete PDF form - only the fingerprint and the postal address are as in 2011 (Denistone East) and not as on the wiki page (as in 2019).

This can help for the moment.
(0005746)
L10N   
2019-01-22 21:49   
To get back the service we had before:
Where pointed pdf.cacert.eu?

If we will run the old service at www.cacert.org again:
How can we change address/fingerprint to use the form with the old address?
(0005747)
L10N   
2019-01-22 22:04   
Following the internet archive, cacert.eu ("CAcert community portal") has gone between September 14th, 2017 and March 28th, 2018.
https://web.archive.org/web/20170914222137/http://cacert.eu/
(0005750)
L10N   
2019-01-26 22:36   
I changed the wiki code from coapHTML and coapHTML_de as described in http://bugs.cacert.org/view.php?id=1456#c5745

The issue still remaining: Fingerprint and postal adress are still wrong, as the came not from the wiki, but from somwhere else. I suppose, it is to change at http://svn.cacert.org/CAcert/Forms/src/form_fies.php (but this is just a supposition and I cannot test it, as I do not have writing access to svn).
(0005751)
L10N   
2019-01-26 23:56   
A community member wrote:

> Unfortunatelly the exchange of the address parts does not work, when I
> do it. Please see the attachment.
>
> What can I do else?
> I think, if nothing else works, I can print the browser page. I will ask
> the assurer. At last it's all paper...

I tried it on Firefox, PaleMoon, Vivaldi and Chromium browsers. For me, it worked on Firefox and PaleMoon, but not on Chromium and Vivaldi browsers. There it gave the same error message as reported by the member.

-----------------------------------
Datei nicht gefunden
Die Datei https://www.cacert.org
/coapnew.php?name=Example+Company+AG&
address=Hans-Knöll-Straße+1,+07745+Jena,+Germany&
type=Partnerschaftsgesellschaft&state=eingetragen (schnipp)

konnte nicht
gefunden werden. Bitte überprüfen Sie die Adresse und versuchen Sie es
erneut.
Könnte der Eintrag umbenannt, gelöscht oder verschoben worden sein?
Enthält die Adresse einen Rechtschreib-, Groß-/Kleinschreibungs- oder anderen
Schreibfehler?
Haben Sie ausreichende Zugriffsrechte für den angeforderten Eintrag?
(0005752)
Ted   
2019-01-27 13:48   
Moved the issue to the "Main Website" project, since the major problem obviously is coap.php respectively coapnew.php on the main website.
(0005753)
Ted   
2019-01-27 13:58   
The problem seems to be coapnew.pdf.

When I access https://test.cacert.org/coapnew.php I get a "file not found" error. When trying to start the script from the shell it says :
require_once(/usr/share/tcpdf_php4/config/lang/eng.php): failed to open stream: No such file or directory in /home/cacert/git/cacert/www/coapnew.php on line 319

Probably the TCPDF library is not installed on the webserver. Wytze can you have a look at this and install the library? Or forward this case to someone who can?
(0005754)
Ted   
2019-01-27 14:02   
Note that this script is (as far as I can see) nothing that has to be run on the critical system. It just creates a nice looking PDF from the form parameters which are transferred from the wiki.

So It was very sensible to install the script on cacert.eu, since changes to non-critical systems are much easier (less formal) than changes to the critical system.

Do we currently have another non-critical system where we can install this?
(0005755)
Ted   
2019-01-27 14:40   
(Last edited: 2019-01-29 14:41)
When I try to access https://www.cacert.org/coapnew.php I get the same error as when accessing https://test.cacert.org/coapnew.php ("File not found". The HTTP error code is 500).

(0005757)
Ted   
2019-01-28 22:40   
With some help from Wytze I managed to run the script from the shell, where it creates an empty COAP form.

When accessed with the browser the following error can be found in apache's error.log:
PHP Fatal error: Allowed memory size of 18874368 bytes exhausted (tried to allocate 65484 bytes) in /usr/share/tcpdf_php4/tcpdf.php on line 2367

This sounds like a strict resource setting of php.ini. I found two php.ini files on the testserver, one at /home/cacert/etc/php5/apache2/php.ini, containing a memory_limit of 128M, and one at /home/cacert/etc/php5/cli/php.ini containing a memory_limit of -1
Playing around a bit with those settings did not change anything, so I'll leave this to people with more proficiency in system administration...

BTW, the TCPDF library seems to be still supported, see https://github.com/tecnickcom/TCPDF, maybe we should switch to a more current version? :-\
(0005758)
wytze   
2019-01-29 11:37   
(Last edited: 2019-01-30 07:53)
I cannot reproduce the error by accessing https://test.cacert.org/coapnew.php, for me that produces a reasonably looking empty COAP form.

However to tackle a PHP memory issue, you should edit /home/cacert/etc/php5/mods-available/cacert,ini, which contains a tighter setting for memory_limit (18M). I have raised to 36M, so you could give your test a new try with that. If you want to increase it even further, please do not forget to "sudo service apache2 restart" after changing the config file.

As for a newer TCPDF version: it is trivial to switch from the -php4 version to a PHP5 version. I have done just that by editing line 233 in coapnew.php:

--- coapnew.php.org 2018-11-27 23:02:24.311871811 +0000
+++ coapnew.php 2019-01-29 11:26:20.661722514 +0000
@@ -230,7 +230,7 @@
 // INSTALLATION DIRS OF PACKAGES ==============================
 // make sure packages are installed here
 define('RT','./');
-define('TCPDF_DIR','/usr/share/tcpdf_php4');
+define('TCPDF_DIR','/usr/share/tcpdf');
 define('UTF8',RT."/utf8/native/core.php");
 if( file_exists(RT.'/transtab.php') ) // wherever it is
     define('UTF8_ASCII', RT.'/transtab.php');

This makes a lot of sense I think, and at the very least reduces the number of PHP5 deprecated teature warnings.

Please also note that HTTP error 500 does not mean "File not found" as some browsers say, rather it indicates an internal server failure. An example of that is PHP running out of memory.

(0005760)
GuKKDevel   
2019-02-01 15:32   
Did someone change something in productive system?

I gave it a try and the form was displayed.

so only have to change address and SHA checksums.
(0005761)
GuKKDevel   
2019-02-01 15:37   
Tried it a second time and it gave an error.

need all logs for time 2019-02-01-T16:20 to 2019-02-01-T16:40 in productive system.
(0005763)
wytze   
2019-02-01 15:49   
Providing all log data would be a serious breach of privacy. I will append the Apache2 access log and error log filtered on your IPv4 address, and with the address replaced by "YOUR-IP-ADDRESS" for privacy.
(0005772)
Ted   
2019-02-14 21:35   
I just found out that for me https://secure.test.cacert.org/coapnew.php works while https://test.cacert.org/coapnew.php gived an HTTP error.

The main website gives the same results, the "secure" server works, the "www" server does not.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1454 [Main CAcert Website] website content major sometimes 2018-12-28 04:28 2019-02-07 22:53
Reporter: bdmc Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: needs review & testing Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Revise Password Reset page to reduce repayments
Description: The messages and instructions on the Password Reset page ( page 5 ) are unclear regarding the proper procedures, especially regarding the "donation" required before requesting that Support assist.
Tags: password recovery, support
Steps To Reproduce:
Additional Information:
Attached Files: Support.odt (27,211 bytes) 2019-01-02 00:42
https://bugs.cacert.org/file_download.php?file_id=463&type=bug
Notes
(0005716)
bdmc   
2018-12-28 04:43   
Page URL: https://www.cacert.org/index.php?id=5
(0005717)
bdmc   
2018-12-30 05:46   
I have created a new version of Page 5, containing many more instructions. I have also said that asking Support for help will take a long time, although I did not specify any time estimate. The code is checked in as "bug-1454," but only consists of one file different from "release."
(0005718)
bdmc   
2018-12-30 05:49   
I have been thinking about Etienne's suggestion for some kind of instruction document to be sent to users.

That might be triggered by the Paypal Payment "success return" message, because that is the only thing that happens before the user is expected to write an e-mail message to Support.

Alternatively, some kind of automatic reply to e-mail messages to Support, with the Subject "Password Recovery Request," might be a way to do it.
(0005719)
L10N   
2018-12-30 09:35   
The message that the user sends with the web form probably goes to support@c.o. At the same time a copy should be sent to a new address password-reset@c.o. (or only to password-reset@c.o.).

This address replies automatically (with 'support' as the sender) with a nice reply, which explains the procedure step by step. And in such a way that the next steps are delegated to the user.

This would have the advantage that the user could help himself in some cases (relieves support). In other cases other people could help (e.g. local assurers). Third, we would have a clear situation with Paypal: Support answered immediately. We are now waiting for further information from the user. Paid service (as Paypal will always consider it) has been provided.
(0005720)
L10N   
2018-12-30 10:01   
Content (keyword) for an automatic reply:

Thanks for contacting us
Empathy for existing problem
Promise to help
Please document everything

Step 1: with certificate (tried on ...)
Step 2: Five questions (tried on ...)
Step 3: With Assurance
3a: If no Assurer nearby known: secretary.c.o requested for addresses from the public part of the WoT directory (requested on..., reply received on...)
3b: Assurer 1 contacted on... (if no replay within 3 days, Assurer 2, 3, 4, 5 contacted)
3c: Assurer met on....
3d: C-word received from Support on....
3e: Answered to Support answered (password reset allowed) on....
3f: T-word from support received on: ....
3g: Congratulations, now you can reset the password yourself. To do this, log into your account. As a provisional password, use (with no space in between): A-word T-word
Step 4: It didn't work. Write to support, include documentation of the first 3 steps with data and assurers.
(0005721)
L10N   
2019-01-02 00:42   
What about this? (Draft, in German)
If possible, send only part 1-2 and part 3 24hrs later.
(0005734)
L10N   
2019-01-13 23:03   
What about a new e-mail-address for password recovery that answers automated (see above); only the second contact goes to support?
(0005735)
bdmc   
2019-01-14 07:11   
I should have responded to this a few days ago, when you first proposed it.

Yes, I like the idea of a special e-mail address for password recovery, and, as you say, perhaps don't send directly to the Support mailing list.

We could never send mail for password recovery to the Support mailing list, or only after the user has accomplished all other tasks. Mail to the password recovery address could be forwarded to Support, or the user would be directed to the Support mailing list only at the end of the process.
(0005736)
L10N   
2019-01-14 13:57   
Until now: User forgot password
-> read wiki, help himself OR most: -> @ to support@c.o. (not support@lists.c.o.)

It could be this way: User forgot password
-> read wiki, help himself OR most: -> @ to new-password-recovery-address@c.o. -> automated answer with help, step 1&2, -> after 24 hours automated answer2 with help, step 3&4, -> after 24 hours automated3 answer with help, step 5&6 (while 6 means contact support and giving the address from support)

If this is to complicated (automated following mails):

It could be this way: User forgot password
-> read wiki, help himself OR most: -> @ to new-password-recovery-address@c.o. -> automated answer with help, step 1-6 (while 6 means contact support and giving the address from support)

The phasing makes sense, as the requestor should do several things before contacting support. On the other hand, you can only send one reply with everything, because there are certainly people who have read the wiki before...

Even if the draft is in German, it's worth looking at it, possibly with an automatic translator, to see how it's planned.
(0005764)
L10N   
2019-02-07 22:53   
I just asked the e-Mail-member of the Infrastructure Team, if an auto responder can be implemented with the available resources. Original Message in German.



-------- Original Message --------
Subject: Auto responder
Date: Thu, 07 Feb 2019 22:44:19 +0000

(...)

Im Moment kläre ich verschiedene Möglichkeiten ab, um den Support bei
verlorenen Passwörtern zu entlasten. Kannst du mir bitte deine ehrliche
EInschätzung zu den folgenden Punkten abgeben, denn nicht alles, was
technisch möglich ist, ist bei uns oder mit den verfügbaren Resourcen
umsetzbar.

- Ist es möglich, eine neue e-Mail-Adresse aufzusetzen, welche automatisch
mit einem vorgegebenen Text/Mail antwortet? (Das eingehende Mail kann
unbesehen vom Inhalt gelöscht werden, es sollte aber nachvollziehbar sein,
wann es eintraf, von welcher Adresse und dass die automatische Antwort
hinaus ging.)

- Ist es möglich, eine neue e-Mail-Adresse aufzusetzen, welche *mehrmals*
automatisch mit einem vorgegebenen Text/Mail antwortet? Also wie oben
einmal sofort und zu vorgegeben Zeitunkten (z.B. 24h später, 36h später)
noch Mail 2 und Mail 3 losschickt?

Was technisch im Hintergrund abläuft, resp. ob das über Mail oder eine
Liste läuft, spielt keine Rolle... ich möchte nur gerne wissen, ob so
etwas mit vertretbarem Aufwand bei uns machbar/möglich ist.

Danke für eine kurze Antwort und
freundliche Grüsse
(...)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1453 [Main CAcert Website] website content feature N/A 2018-12-09 23:24 2018-12-09 23:24
Reporter: L10N Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions: (number) paypal button(s) are shown on https://www.cacert.org/account.php?id=6&cert=xyz and in working order.
Summary: Donation button on certificate issuing page
Description: "Comment from Philipp; Add donation button to page where people successfully get their certificate."
source: https://bugs.cacert.org/view.php?id=1305 (>2009)

This page would be https://www.cacert.org/account.php?id=6&cart=xyz (cert number)
accisble trough https://www.cacert.org/account.php?id=5 and then clicking of the e-mail-address of any issued certificate
Tags: certificates, finances, future, html, new feature
Steps To Reproduce:
Additional Information: A possibilty (with german text an more than one paypal button is given in the pictures.
Attached Files: as-it-is.png (211,424 bytes) 2018-12-09 23:24
https://bugs.cacert.org/file_download.php?file_id=455&type=bug
as-it-should.png (181,562 bytes) 2018-12-09 23:24
https://bugs.cacert.org/file_download.php?file_id=456&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1452 [Main CAcert Website] translations minor always 2018-12-06 12:17 2018-12-06 12:17
Reporter: GuKKDevel Platform: Test CAcert Website  
Assigned To: OS: N/A  
Priority: normal OS Version: Test  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: changing the default language doesn't change the language for CAP-forms
Description: beeing logged in and changing the default language doesn't change the language for CAP-forms automatically
Tags: Translation
Steps To Reproduce: 1. log in
2. create CAP-form -> is in your default language
3. change default language
4 create CAP-form -> still the old language

Additional Information:
System Description Test version of the CAcert website
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1031 [Main CAcert Website] Audit issues major always 2012-04-09 03:12 2018-11-18 13:46
Reporter: clopez Platform: Default  
Assigned To: Patrick OS: any  
Priority: high OS Version: any  
Status: fix available Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Disable use of insecure function mysql_escape_string()
Description: mysql_escape_string() is insecure

 * http://security.stackexchange.com/questions/8028/does-mysql-escape-string-have-any-security-vulnerabilities-if-all-tables-using-l

And its used on core parts like password user logging:

$ grep -rl mysql_escape_string .
./includes/lib/general.php
./www/wot.php
./www/disputes.php
./www/verify.php
./www/alert_hash_collision.php
./www/index.php
./www/api/cemails.php
./www/api/edu.php
./pages/wot/12.php
./pages/wot/13.php
./pages/account/43.php
./pages/account/53.php
./pages/account/41.php
./pages/account/54.php
./pages/account/49.php
./tverify/index.php


Theoretically this can be exploited to perform a SQL Injection attack.


Please replace all mysql_escape_string() occurrences with the secure mysql_real_escape_string(

You can do this simply executing this command on the topdir:

grep -rl mysql_escape_string . | xargs sed -i "s/mysql_escape_string/mysql_real_escape_string/g"
Tags:
Steps To Reproduce:
Additional Information:
System Description Default profile.
Attached Files:
Notes
(0005336)
Patrick   
2015-02-27 22:06   
I quickly wrote the fix.

https://github.com/DjBusti/cacert-devel/commit/c7ec6a2aa2edc6d59578d5adc685de01d4497461
(0005684)
Ted   
2018-11-18 13:46   
Note that 0001442 also replaces mysql_real_escape_string, by mysqli_real_escape_string.

So, once bug-1442 is installed this issue is obsolete.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1194 [Main CAcert Website] misc minor have not tried 2013-07-23 22:20 2018-11-16 10:37
Reporter: NEOatNHNG Platform:  
Assigned To: NEOatNHNG OS: Windows  
Priority: normal OS Version: 8  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Root certificate installer MSI package fails on Windows 8
Description: There are some problems when using the installer package on Windows 8
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0004204)
NEOatNHNG   
2013-07-31 12:49   
This seems to be a problem with the WiX toolkit used. One upstream bug report can be found on http://sourceforge.net/p/wix/bugs/1369/ but that should have been fixed since WiX 3.5 and I have used 3.7 to build the package. Seems I have to dig a little further.
(0004483)
NEOatNHNG   
2013-12-11 00:53   
http://wixtoolset.org/issues/4212/


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
156 [Main CAcert Website] source code tweak always 2006-03-05 21:42 2018-11-11 18:37
Reporter: bluec Platform:  
Assigned To: bluec OS:  
Priority: low OS Version:  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: magic_quotes_gpc vs. mysql_escape_string()
Description: I see many cases where mysql_escape_string() is applied to $_REQUEST, $_POST or $_GET. As magic_quotes already escaped these strings this may lead to corruption of the userinput.

e.g. in api/ccsr.php

        $username = mysql_escape_string($_REQUEST['username']);
        $password = mysql_escape_string($_REQUEST['password']);

I recommend using something like quote_smart() from php.net

  function quote_smart($value)
  {
     // stripslashes, if necessary
     if (get_magic_quotes_gpc()) {
         $value = stripslashes($value);
     }

     // quote, if not numeric
     if (!is_numeric($value)) {
         $value = "'" . mysql_real_escape_string($value) . "'";
     }

     return $value;
  }


Additionally since PHP 4.3.0 it's recommended to use mysql_real_escape_string().
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0000523)
duane   
2006-08-16 13:36   
We need patches and/or source locations, this bug isn't a simple one and feeds back into the requirement to turn off globals...
(0001010)
dionyziz   
2008-02-18 13:42   
I can confirm this bug exists for the "Contact Information" field of the "My Listing" section.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1448 [Main CAcert Website] source code minor have not tried 2018-11-09 22:06 2018-11-11 18:37
Reporter: Ted Platform:  
Assigned To: pmoulding@cacert.org OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Convert to new error class
Description: Reported by pmoulding:

PHP now has an error class and conflicted with the error class already used in openbiblio

As far as the 'error class,' it means isolating all of the error-handling code into a single area, and make calls to that code for both error handling and error reporting.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1446 [Main CAcert Website] General minor have not tried 2018-11-04 04:51 2018-11-11 18:36
Reporter: pmoulding@cacert.org Platform: Test CAcert Website  
Assigned To: pmoulding@cacert.org OS: N/A  
Priority: normal OS Version: Test  
Status: needs work Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Add an autoloader as a step toward moving common code into classes
Description: Common code should be in classes. Classes can be delivered from a single class directory. An autoloader can make the class loading automatic. The autoloader can replace the multiple occurrences of require/require_once.

The autoloader class could also replace the prepend defined in the Apache config file, removing a roadblock for people who cannot access their Apache settings.
Tags:
Steps To Reproduce:
Additional Information: Create a directory outside the Web root named class or the same directory inside the Web root with a Web server config line to limit access to the class directory.
Create a class named cacert in a class file named cacert.php in the class directory.
Add common code to every page to start with the loading of the cacert class.
In the constructor of cacert, register an autoloader function named autoloader.
Create the autoloader function to load classes from the class directory if they exist.

The class could also set directory paths and other similar values, such as the domain name, for use on every page.
System Description Test version of the CAcert website
Attached Files: cacert.php (36 bytes) 2018-11-04 07:01
https://bugs.cacert.org/file_download.php?file_id=441&type=bug
index.php (26,831 bytes) 2018-11-04 07:01
https://bugs.cacert.org/file_download.php?file_id=442&type=bug
cacert.ini (221 bytes) 2018-11-04 07:03
https://bugs.cacert.org/file_download.php?file_id=443&type=bug
cacert-2.php (359 bytes) 2018-11-04 07:03
https://bugs.cacert.org/file_download.php?file_id=444&type=bug
cacert-3.php (2,264 bytes) 2018-11-04 07:03
https://bugs.cacert.org/file_download.php?file_id=445&type=bug
Notes
(0005647)
pmoulding@cacert.org   
2018-11-04 07:01   
I modified index.php in my test to include a cacert.php.
(0005648)
pmoulding@cacert.org   
2018-11-04 07:03   
The included cacert.php brings in a common cacert.php file from outside the Web root. There is a .ini file at the same level.
(0005649)
pmoulding@cacert.org   
2018-11-04 07:03   
The cacert.php file includes class/cacert.php
(0005650)
pmoulding@cacert.org   
2018-11-04 07:07   
This structure was copied from other projects. You might like to work on the names, locations, and what is included from the .ini. I started a separate issue for the .ini and included the .ini here only as a simple way to load the .ini. The contents of the .ini would be better discussed in the other issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1253 [Main CAcert Website] website content minor have not tried 2014-03-02 11:22 2018-11-05 10:36
Reporter: INOPIAE Platform:  
Assigned To: egal OS:  
Priority: normal OS Version:  
Status: needs review Product Version: 2014 Q1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2015 Q2  
Reviewed by: Ted
Test Instructions: Cause error messages and see if the HTML is using CSS classes instead of style attributes
Summary: Remove deprecated <font> formatting
Description: The font tag is deprecated. Use span or div instead and possibly create a proper CSS class for it (or reuse an existing one).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0004615)
MartinGummi   
2014-03-04 21:24   
FIX https://github.com/magujs/cacert-devel/tree/bug-1253
(0005280)
INOPIAE   
2015-01-27 21:03   
I tried to long in with a wrong passphrase.
In the html code there was no font tag around the error message.
0> OK
(0005281)
Eva   
2015-01-27 21:16   
It would be nice to know where there can be errors to be able to test them.
(0005306)
Eva   
2015-02-03 21:26   
Benny collected the following error messages (copy from pad):
- account_stuff: Allgemeine Account-Fehler-Meldungen
- general_stuff: Allgemeine Fehler-Meldungen
- includes/shutdown.php
- (tverify-Fehler)
- account/14: Pass Phrase der *
- (account/40: Mailinglist Note)
- index/0: disabled functions ...
- index/1: Pass Phrase der *
- (index/11: Mailinglist Note)
- index/6: Pass Phrase der *
- wot/1: CATS/Assurer
- wot/5: Allgemeine Fehlerausgabe
- wot/8: Allgemeine Fehlerausgabe
- wot/9: Allgemeine Fehlerausgabe
- www/gpg: GPG-Key-Fehler
- www/wot: Allgemeine Warnungsausgabe
(0005331)
Eva   
2015-02-24 22:06   
(Last edited: 2015-03-03 22:07)
Could test without issues:
account/14 -> ok
index/1 - multiple situations -> ok
index/6 - multiple situations -> ok
wot/5: Allgemeine Fehlerausgabe - multiple situations -> ok
www/wot: Allgemeine Warnungsausgabe -> ok [however the error as such is wrong]
gpg: GPG-Key-Fehler -> ok

not testable without access to testserver:
includes/shutdown.php
index/0: disabled functions ...

not testable at all, as it was removed:
(tverify-Fehler)
(account/40: Mailinglist Note)
(index/11: Mailinglist Note)

account_stuff: Allgemeine Account-Fehler-Meldungen
- unsure what this should be, some account errors produced at index/1 -> ok?

general_stuff: Allgemeine Fehler-Meldungen
- unsure what this should be
file not founds -> ok


Could not produce the errors on the following pages - according to Felix they are deleted before they are shown
wot/8: Allgemeine Fehlerausgabe
wot/9: Allgemeine Fehlerausgabe

Even as there should be a situation where the following page displayed an "error" in the tables for user who have no CATs but 100 points, those users were just not shown, so could not test this error:
wot/1: CATS/Assurer
edit: could see this later -> ok


General note:
It would be good if errors were displayed always in the same manner.

=> those that I could produce were OK - could not do complete test

(0005351)
BenBE   
2015-03-03 21:26   
added:
- includes/account.php
- includes/keygen.php
- pages/advertising/1.php
(0005352)
INOPIAE   
2015-03-03 21:27   
(Last edited: 2015-03-03 21:37)
tested:
all wot/pages all displayed error showed an error class => ok
index/1 and 6 all displayed error showed an error class => ok

account/14 all displayed error showed an error class => ok

advertising/1 displayed error showed an error class => ok
 => ok

(0005353)
Eva   
2015-03-03 21:54   
(Last edited: 2015-03-03 22:03)
- includes/account.php is
account/14 -> is improved compared to last test
-> ok

- includes/keygen.php
-> needs IE without activeX - I do not have access to this browser at the moment, so no test from me for this
-> not tested

- pages/advertising/1.php is
advertising.php?id=1 - I do not see anything there
-> ok
(Hint: you need to have Add Admin rights = 1 - relog after you set this flag)


=> OK, as far as I could test it (did not retest other things)

(0005354)
BenBE   
2015-03-03 22:12   
As the bugtracker currently doesn't show the patches you can find them alternatively https://github.com/CAcertOrg/cacert-devel/compare/release...bug-1253
(0005611)
Ted   
2018-10-20 21:56   
(Last edited: 2018-10-20 21:56)
I removed a trailing semicolon in one style attribute.
The specification at https://www.w3.org/TR/css-style-attr/#Syntax%20and%20Parsing does not allow trailing semicolons in style attributes, though AFAIK it is tolerated by most browsers.

Since this is in fact a fallback to the previous version (and an extremly minor change) I don't think that this has to go through testing once more.

All other changes are acceptable. One might argue the class names, since "error_indicator" is used to indicate (IMHO) warnings in some places, but insisting on a change here would be nitpicking. I'll leave this to a followup bug report if someone also feels this way.

The review is PASSED.

(0005612)
Ted   
2018-10-20 22:18   
Hmm, this issue has already been reviewed by BenBE in 2015, and AFAIK he was a Sofrware Assessor then. So this issue might be considered as reviewed by two SAs, but there have been code changes (beyond my little one) after BenBEs first review...
(0005654)
Ted   
2018-11-05 10:36   
Dirk, can you just give a second review? It's a quite easy job, and could help to warm up for the other jobs to follow...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1439 [Main CAcert Website] misc major always 2018-05-13 19:14 2018-11-01 21:12
Reporter: Ted Platform:  
Assigned To: egal OS:  
Priority: normal OS Version:  
Status: fix available Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Reviewed by:
Test Instructions:
Summary: Changes needed for cats_import.php for new PHP version
Description: As noticed by Wytze, the old version of cats_import.php seems not to work with the updated OS (Debian
Jessie). Obviously the format of the server variable SSL_CLIENT_S_DN has changed, so matching the Upload DN does not work anymore.

Wytze has installed a hotfix to get the CATS result upload working again, but there is also another issue here when checking for the DN, the check should make sure that the complete emailAddress field is checked, the current check could probably be fooled by a certificate issued for cats@cacert.org.evildomain.com. I guess that was the intention of the reviewer's comment, but it looks like I did not get it then... :-(
Tags:
Steps To Reproduce:
Additional Information: Complete mail from Wytze:

Hi Ted,

Since we have upgraded the CAcert chroot application environment to Debian
Jessie on the webdb production server, it appears that import from CATS
does not work anymore. I noticed these messages in the errorlog:

[Sun Apr 29 06:35:01.458559 2018] [:error] [pid 17899] [client
213.154.225.243:59570] PHP Fatal error: Unauthorized access:
ip(213.154.225.243) server(secure.cacert.org) https(on)
cert(emailAddress=cats@cacert.org,CN=CAcert WoT User) in
/www/www/cats/cats_import.php on line 60

Looking at the code, it seems that the match for the e