openca-devel Mailing List for OpenCA

Hi OpenCA developers,

I have put together a collection of patches for openca-base-1.5.1 which
I have developed over the last months. Some of them depend on each
other. However, I have made them all to apply to an unpatched
openca-base-1.5.1 source. If you want to apply several (or all of them)
together, you might have to edit them slightly, but since I'm posting to
the developer's list I assume that everybody has the programming skills
for these minor adjustments...

Here the description of the patches included in the attachment:

openca-fix_getcert.patch : when trying to download the own certificate
by serial# it is not found in the db. This patch fixes the issue by
setting the "key" for which the db is searched equal to the serial
(which is what one would expect to happen).

openca-fake_email_verification.patch : This allows the CA/RA operator to
mark email-addresses as "verified" without actually sending a mail to
that address.

openca-change_auto_defaults.patch : This patch switches off debugging
and tries to enable startup of the autoCRL and AutoEmail daemon. Well,
the startup does not work like this, but at least the default settings
seem to be more reasonable for a production environment

openca-list_unverified_csr.patch : If the verification mail does not
arrive (e.g. filtered out by a spam filter on the mail server already) -
the csr is not accessible and the user has no chance to click on the
verification link to make it appear. This patch adds a category of
"unverified" signing requests in the CA/RA backend which allows the
operator to edit or approve the requests.

openca-allow_renew_cert.patch : This allows the user to renew his
certificate. We query for the PIN of the original CSR for security
reasons and only allow the operation onn valid certificates (expired
ones might have been revoked before which is not so easy to distinguish
once the certificate has expired).
This patch also depends on the allow_reuse_of_key-patch below

openca-fix_send_pin_mail.patch : OpenCA supports two sorts of PINS to
revoke certificates: Use the requests PIN or use so-called CRINs
(Certificate revocation identification numbers), which are sent
encrypted to the owner of the request. However, many users have not
enough skills to deal with CRINs. And the support for using the original
PIN of the CSR instead is buggy. This patch fixes these issues and
switches the default config to use REQUEST_PINs.

openca-check_subject.patch : We had trouble that users often enter a
trailing space character when filling in the request form. This patch
warns about such weird certificate subjects

openca-process_alternative_mails.patch : For server certificates it is
sometimes advantageous not to include an email-address in the
certificate. However, there is a field for an additional email-address.
This patch adds that one to the headers of the csr and verifies it when
no email is included in the certificate itself

openca-mod_ssl-auth.patch : x509 authorization in recent firefox
versions requires an extra addon. This addon is still needed to sign
requests in the RA interface, but this patch implements an authorization
based on apache mod_ssl for logging in to the interfaces. If you apply
this, be aware that it is your task to set up a proper apache
configuration for mod_ssl.

openca-update_emails_in_cert_header.patch : together with the
fake_email_verification this patch adds the information about verified
email addresses to already issued certificates.

openca-allow_reuse_of_keys.patch : re-using a private key for a new
certificate per se is not a bad thing. Of course the operator has to
check if the requestor is authorized to request a certificate for the
particular server. If a private key is compromised and the revoked
certificate expires, it is possible to request a new certificate for
that key. However, the server admin should not do this and the RA
operator should carefully check who is requesting a certificate. Denying
to reuse keys at all solves these problems, but it makes it impossible
to extend certificates. This patch allows to reuse keys and implies the
before mentioned duties.

openca-getcert_send_pem.patch : For our applications pem-files are
preferred over p12 encoded ones. This patch changes the default format
in which the certificates are delivered to the users

openca-fix_typos.patch : two typos in mail-utils.lib which have been
reported on the mailing-list by someone else already - just for completeness

openca-include_cert_in_notification.patch : A handy thing would be to
attach the certificate to the notification mail sent out to the user.
However, we would need MIME-multipart messages like in the CRIN-mails
here, which is quite some effort. This patch just includes the
pem-formatted certificate in the message body (still more comfortable
than only a download link which requires lan access - the mail itself
might be in the local cache of the mail client).

openca-make_search_more_flexible.patch : This patch fixes some problems
with searching for certificates and makes it more flexible. You can
search for DN, request serial, serial, in decimal or hex in different
formats (the flexibility in the format of the serial and the ability to
search for the request serial have been added in this patch)

openca-send_verify_message.patch : If the verification mail got lost
somehow (e.g. the server's mail configuration not yet finished when
requesting a certificate) it is not possible to verify the email-address
anymore. This patch allows the RA/CA operator to send out another
verification mail if needed.

openca-make_manual_mail_verbose.patch : Manually sending out queued
mails asks the operator to wait until sending has finished, but it stays
quiet all the time. This patch prints out the information what's going
on to the web interface so that the operator can see if it is still
running.

I hope that the attachment is not stripped off when sending this to the
list... otherwise I'll retry with uncompressed attachments.

best regards,
Martin

Hi all,

sorry, I was too enthusiastic about this, yesterday. Have a look at the
release notes: https://www.mozilla.org/en-US/firefox/34.0.5/releasenotes/
It sais:  "Proprietary window.crypto properties/functions re-enabled (to
be removed in Firefox 35)" - i.e. Mozilla is just giving us some more
time to change the web interfaces. Unfortunately, the proposed
replacement, the webcrypto api, http://html5.creation.net/webcrypto-api/
is not yet stable, nor fully implemented yet.

Martin


On 12/18/2014 02:43 PM, Nuno Dias wrote:
>  Hi Martin,
>
>  Yes, you are right, I upgraded my machine to Fedora 21 that comes with
> Firefox 24 and I can sign the request again.
>
> Thanks,
> Nuno

Hi Nuno,

maybe I have good news about this issue:

When Firefox 33 came out, I wasn't even able to sign the challenge in
the web interfaces (which I have configured for login via certificate).
In the meantime I was using Firefox 31 ESR and now that I have found
some time and started to look into this issue it suddenly works again
(at least to sign the challenge). I'm using "Mozilla Firefox 34.0 for
Ubuntu canonical - 1.0" now together with OpenCa 1.5.1. So, maybe
Mozilla or the team from Ubuntu who integrate it into the distribution
have solved this problem in the meantime. Maybe you could try it in your
environment?

Signing the requests didn't work in my setup anyway (I have separated
the web-components on different hosts without a shared file system and
signing the requests seems to use the files in addition to the database
at some point - so I issue the certificates directly by logging into the
Ca interface with my operator certificate). I would have to set up a
separate test environment to verify exactly your scenario, but I could
do so if I find the time between the years.

best regards,
Martin

On 11/06/2014 04:23 PM, Nuno Dias wrote:
>  Hi Martin,
>
>  Yes, although is not a solution, Firefox 31 can sign the requests, in
> Opera I can't even load a certificate :(
>
> Cheers,
> Nuno
>
> On Thu, 2014-11-06 at 11:45 +0100, Martin Hecht wrote:
>> Hi Nuno,
>>
>> I haven't a solution yet, but a workaround could be to use the Extended
>> Support Release 31 of Firefox which still works with this  signing
>> procedure. It is available here: ​
>> http://www.mozilla.org/en-US/firefox/organizations/all.html and
>> presumably gets updates until summer 2015.
>>
>> Alternatively, a colleague just mentioned Opera 12 which works according
>> to him...
>>
>> best regards,
>> Martin
>>
>> On 11/05/2014 06:32 PM, Nuno Dias wrote:
>>>  Hi all,
>>>
>>>  Since the last update of firefox (33) I can't sign certificates
>>> requests, the openca version is 1.1.1, and I get this error in the
>>> console of firefox
>>>
>>> "Netscape" signForm.js:4
>>> "crypto supported on firefox!" signForm.js:6
>>> TypeError: theWindow.crypto.signText is not a function signForm.js:54
>>> "Netscape" signForm.js:4
>>> "crypto supported on firefox!"
>>>
>>> I saw the code of the last version of openca (1.5.0) and the signForm.js
>>> has the same call, anyone can advise a solution to this problem?
>>>
>>> Thanks,
>>> Nuno

Hi Nuno,

I'm cc'ing the developers list as well. 

Mozilla has removed some crypto functions which OpenCA uses in Firefox 33:
https://wiki.mozilla.org/SecurityEngineering/Removing_Proprietary_window.crypto_Functions

As a replacement they propose the webcrypto API:
http://html5.creation.net/webcrypto-api/

For signing certificates I'm using the ESR branch of Firefox as a
workaround until we have an updated CA package.
As far as I can see, for users the browser based requests are working
with the latest Firefox as well, so only the CA/RA-operators need a
special workaround at the moment.

I'll try to look into this, but to be honest, I have no clue yet how
much work this means and how much time I can find in the near future.
Maybe someone else on the developers list has already done some work on
this?

best regards,
Martin

PS: I didn't verify my colleague's hint about Opera - I'm sorry if you
wasted your time due to my previous post.

On 11/06/2014 04:23 PM, Nuno Dias wrote:
>  Hi Martin,
>
>  Yes, although is not a solution, Firefox 31 can sign the requests, in
> Opera I can't even load a certificate :(
>
> Cheers,
> Nuno
>
> On Thu, 2014-11-06 at 11:45 +0100, Martin Hecht wrote:
>> Hi Nuno,
>>
>> I haven't a solution yet, but a workaround could be to use the Extended
>> Support Release 31 of Firefox which still works with this  signing
>> procedure. It is available here: ​
>> http://www.mozilla.org/en-US/firefox/organizations/all.html and
>> presumably gets updates until summer 2015.
>>
>> Alternatively, a colleague just mentioned Opera 12 which works according
>> to him...
>>
>> best regards,
>> Martin
>>
>> On 11/05/2014 06:32 PM, Nuno Dias wrote:
>>>  Hi all,
>>>
>>>  Since the last update of firefox (33) I can't sign certificates
>>> requests, the openca version is 1.1.1, and I get this error in the
>>> console of firefox
>>>
>>> "Netscape" signForm.js:4
>>> "crypto supported on firefox!" signForm.js:6
>>> TypeError: theWindow.crypto.signText is not a function signForm.js:54
>>> "Netscape" signForm.js:4
>>> "crypto supported on firefox!"
>>>
>>> I saw the code of the last version of openca (1.5.0) and the signForm.js
>>> has the same call, anyone can advise a solution to this problem?
>>>
>>> Thanks,
>>> Nuno


-- 
Dr. Martin Hecht
High Performance Computing Center Stuttgart (HLRS)
Office 0.051, HPCN Production, IT-Security
University of Stuttgart
Nobelstraße 19, 70569 Stuttgart, Germany
Tel: +49(0)711/685-65799  Fax: -55799
Mail: he...@hl...
Web: http://www.hlrs.de/people/hecht/
PGP Key Fingerprint: 41BB 33E9 7170 3864 D5B3 44AD 5490 010B 96C2 6E4A

https://github.com/openca/libpki/pull/3

 

This patch adds an extension to the basic response created that specifies
that our OCSP responder knows of the RFC6960 new Extended Revocation status.
For this reason we also supply a new libPKI API call, PKI_TIME_set, so the
OCSP responder can set the revocation time to "1 January 1970".

 

https://tools.ietf.org/html/rfc6960#section-2.2

https://github.com/openca/openca-ocspd/pull/4

This pull request adds a .travis.yml YAML file that instructs Travis-CI 
how to build OCSPD.

 <https://github.com/openca/openca-ocspd/pull/3>
https://github.com/openca/openca-ocspd/pull/3

This pull request supplies 2 patches.

The first patch was submitted by Sylvain Munaut
(http://sourceforge.net/p/openca/mailman/message/32812416/) and fixes
multiple token handling. (SHA1: e6dd747e556f4c968d11f7cbd06c1e2692cacc18 ).

 

The second patch was submitted by me and fixes the CA selection logic; due
to 2 misplaced continue statements, CA selection would only work when run
with -debug. (SHA1: 10a64457107462a111148d43b7ca85e2a45383f4)

 

 

CA/B Forum guideline v1.1.9 (since v1.0.3) Section 13.2.6 demands that 
an OCSP responder should not return GOOD to a request about an 
unrecognized serial. This patch implements that by logging the unknown 
serial and returning UNAUTHORIZED to the client. The serials are 
provided by a file that is specified in the CA configuration. A timeout 
option is supplied to reload the file each 'timeout' seconds. The 
serials file must be plaintext with each serial in hex (w/o "0x") and 
delimited by "\n".

The pull request in question is this: 
https://github.com/openca/openca-ocspd/pull/2

Hi All,

As many of us have probably had to deal with some pain points when 
developing and/or using applications together with X509 PKIs. I hope 
that the projects we promote (i.e., OpenCA PKI, OpenCA OCSPD, and 
LibPKI) have been helpful in providing useful solution. However, issues 
still exist in interacting with PKIs. In particular, some of the most 
painful areas are related to service (and repository) discovery and 
efficient revocation. Besides implementing specific solutions for 
well-defined (and usually quite closed) environments, no existing 
standards efficiently address these issues.

In the past we participated to discussions within the Internet 
Engineering Task Force (IETF) and implemented the standardized protocols 
(e.g., OCSP). However, the Working Group (WG) that was historically 
responsible for advancing the status of these standards (required for 
interoperability across applications and organizations) was declared 
closed - therefore, today, there is no proper venue where this 
standardization work can happen. It seems that the IETF is still on the 
fence about the need for solving these issues and that strong consensus 
is required in order to open a new WG that will address these problems.

I was wondering what the OpenCA community thinks about the need to 
provide standards that cover the aforementioned issues (e.g., by 
providing enhancements over existing solutions - like OCSP over DNS, by 
providing new more-compact revocation formats that would better cope 
with high-volume transactions environments than OCSP, and - ultimetely - 
by providing PKIX discovery protocols that will ease interacting with 
certificate-related services and with federating identities) and if 
anybody would feel like they can contribute to the discussion and, 
eventually, to the needed work (via the PKIX mailing list - 
https://www.ietf.org/mailman/listinfo/pkix).

If the proposal for working on these issues will move forward, I think 
that the OpenCA Labs could very well work on implementing those 
standards and, therefore, solve those issues for lots of us in a 
standardized and interoperable way.

Cheers,
Max

Hi,

openca usually writes very detailed log files in xml format in
subdirectories below var/log/xml in the openca installation directory.

Maybe there are some hints in these logs. Maybe some hints I have
written down for an installation of openca-1.1.1 compiled from source
may be helpful, too - some other things are probably fixed in the meantime:

On the command line check if the db user configured for the db access
has enough permissions (this is probably true in your case, because at
least the tables have been created, however this could also have been
done by a different process during installation, which ran as a
different user than the openca web service. Check privileges for
different users in mysql)
Locate the file containing the ca-certificate cacert.crt and remove all
lines before "-----BEGIN CERTIFICATE-----". (perhaps this is fixed in 1.5.1)
The automake-macro @dbmodule@ is not always replaced correctly. After
installing replace all occurences of it by "DBI". (perhaps this is fixed
in 1.5.1)
In some places the ca certificate files are missing. Search for broken
links and put another link at the place where they point to, in order to
fix the issue (maybe this is only due to my special configuration).
fix permissions on the file system level. Depending on your installation
you might have to add the web server to the group under which you have
installed the openca software (or vice versa) and make files/directories
group-readable or group-writable. This all depends very much on your
configuration and I don't know how the setup looks like in the
precompiled centos-package. Maybe someone else who used this kind of
installation can have a look.
Finally, go to the web interface and rebuild cachain (but that's the
next step when the ca_certificate appears in the db).

best regards,
Martin

On 05/19/2014 10:05 AM, spd wrote:
> Hi,
> I did a clean install ( system and openCA - using
> openca-base-1.5.1-linux-x64-CentOS-6.4.x86_64.run) I'am facing a problem
> with inserting ca certificate into database. After creating CA certificate,
> in the ca-certificate table there are only nulls:
>
> mysql> select * from ca_certificate;
> +-------------+--------+------+------+------+-------+--------+------------+---
> -------+-----------+-----------------+---------------+-------------------+----
> ---+
>
> | ca_cert_key | format | data | dn   | cn   | email | status | public_key |
>
> notafter | notbefore | suspended_after | revoked_after | invalidity_reason |
>
> rowid |
>
> +-------------+--------+------+------+------+-------+--------+------------+---
> -------+-----------+-----------------+---------------+-------------------+----
> ---+
>
> |             |        |      |      |      |       |        |            |
>        0 |         0 |            NULL |          NULL | NULL              |
>     1 |
> +-------------+--------+------+------+------+-------+--------+------------+---
> -------+-----------+-----------------+---------------+-------------------+----
> ---+
> 1 row in set (0.00 sec)
>
> Any idea what could by wrong?
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> OpenCA-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openca-devel

Hi,
I did a clean install ( system and openCA - using
openca-base-1.5.1-linux-x64-CentOS-6.4.x86_64.run) I'am facing a problem
with inserting ca certificate into database. After creating CA certificate,
in the ca-certificate table there are only nulls:

mysql> select * from ca_certificate;
+-------------+--------+------+------+------+-------+--------+------------+---
-------+-----------+-----------------+---------------+-------------------+----
---+

| ca_cert_key | format | data | dn   | cn   | email | status | public_key |

notafter | notbefore | suspended_after | revoked_after | invalidity_reason |

rowid |

+-------------+--------+------+------+------+-------+--------+------------+---
-------+-----------+-----------------+---------------+-------------------+----
---+

|             |        |      |      |      |       |        |            |
       0 |         0 |            NULL |          NULL | NULL              |
    1 |
+-------------+--------+------+------+------+-------+--------+------------+---
-------+-----------+-----------------+---------------+-------------------+----
---+
1 row in set (0.00 sec)

Any idea what could by wrong?

On 05/10/2014 07:27 PM, Molka Dakhli wrote:
> Hi,
> I installed OpenCA-base.1.5.0 on ubuntu 13.10
> I have a problem in the ldap interface when I want to update the CA
> certificate, it displays an error code: 700 " the command cmdLdapUpdateCA
> failed"
> Please can anyone help me fixing the problem?
looking into the source the command should be
./src/common/lib/cmds/ldapUpdateCA and it should create some log entries.
There should be a log directory where these messages are stored in xml
format. Do you see anything which gives more hints?
The command itself (if nothing goes really wrong) should call
eximObjectToLDAP in ./src/common/lib/functions/export-import.lib which
again should create different log entries depending on what exactly goes
wrong.

best regards,
Martin

Hi,
I installed OpenCA-base.1.5.0 on ubuntu 13.10
I have a problem in the ldap interface when I want to update the CA
certificate, it displays an error code: 700 " the command cmdLdapUpdateCA
failed"
Please can anyone help me fixing the problem?

Dear OpenCA Developers,

I have added the possibility to send another verification mail from the
RA interface.

By default, a new CSR for which the email is not verified yet, is not
displayed at all (TEMPNEW in the database). Some time ago, I have sent a
patch which makes "unverified" requests visible in the CA interface.
That patch is included in the one attached to this mail.

Now, I can access such CSR's and I can edit them and eventually sign
them. But, if the user had a typo in the email-address, and I correct
it, I might want to have that one verified (it is PENDING now). So, I
have added a command that allows to send the verification mail again.

Other use cases are:

Sending mail is impossible due to server misconfiguration, and after
fixing that, the operator wants to send out the verification mails again
for the requests that have been entered into the database in the meantime,

or:

After upgrade from earlier versions of OpenCA, which did not yet support
email verification, all archived requests have un-verified
email-address. When renewing them, it should be possible to send out the
verification message from the (upgraded) Ca.

or:

When adding a new email-Address or changing the email-contact when a CSR
is renewed, one should be able to verify the new contact again.

Please have a look at my patch and consider adding this feature to
future releases of OpenCA.

best regards,
Martin

Hello Martin, I will test and give some feedback about it soon.

However, thanks to a colleague, we be able to patch OpenCA DBI module
and do some tests that fixed both problems in this thread:
 - export/import problems related with CSRs with differents states
 - make complete database backup in which are stored all objects in all
posible categories

After doing some tests, I was able to use these OpenCA funtions without
problems

I attach the patch

Bye

Nicolas Macia
_____________
CERTunlp

El 07/03/14 11:02, Martin Hecht escribió:
> Hello Nicolas,
>
> I think you were looking at the right place. The function exportDB in
> export-import.lib
> holds a list of states which shall be exported. TEMPNEW is not among
> the ones to
> be exported, so these requests which are not validated should not even
> leave the
> RA. Nevertheless, it would make sense to handle TEMPNEW in importObjects
> just in case. However, all other states should already be handled
> correctly, at least
> for Openca-base 1.5.1. In the output below I can't see any export of a
> request.
> Could you try to export the data base with requests of different
> states ( TEMPNEW /
> NEW / APPROVED ) and check the tar file how they are written to the
> device?
>
> best regards,
> Martin
>
> PS: I'm suggesting the attached patch to make sure the TEMPNEW state
> is correctly
> handled during import
>
> On 02/28/2014 03:35 PM, Nicolas Macia (CeSPI) wrote:
>> I left to say that this behavior happend on:
>> - Openca-base 1.5.1 / Openca-tools 1.3.0 on Debian 7 (Stable)
>> - Openca-base 1.1.1 / Openca-tools 1.3.0 on Debian 6 (Old Stable)
>>
>> I think that this problem could be related with another bug related with
>> putting all objects (CA CERT / CERTIFICATE / REQUEST) in all different
>> categories regardless their status: CACERT [valid / expired] , REQUEST
>> [new / renew / pending / signed / approved / archived / deleted] ,
>> CERTIFICATE [valid / expired / revoked / suspended]
>>
>> For example, on OpenCA 1.5.1 on my CA that have:
>> - one CA cert
>> - one CRL
>> - two valid certificates
>>
>> if I make on the node interface:
>> Node Ops -> Backup and Recovery -> Database
>>
>> I can see the following:
>>
>> Thursday 27 February 21:48:13 UTC
>> Exporting DB ...
>> Please wait until operation completes
>> Exporting valid CA_CERTIFICATE ...
>>
>> Exporting all necessary objects.
>>
>> cc2821c7d9025aadb34c467ea115980f3e64690b.pem
>>
>> Exporting expired CA_CERTIFICATE ...
>>
>> Exporting all necessary objects.
>>
>> cc2821c7d9025aadb34c467ea115980f3e64690b.pem
>>
>> Exporting new CRR ...
>>
>> No objects are present.
>>
>> Exporting pending CRR ...
>>
>> No objects are present.
>>
>> Exporting signed CRR ...
>>
>> No objects are present.
>>
>> Exporting approved CRR ...
>>
>> No objects are present.
>>
>> Exporting archived CRR ...
>>
>> No objects are present.
>>
>> Exporting deleted CRR ...
>>
>> No objects are present.
>>
>> Exporting valid CRL ...
>>
>> Exporting all necessary objects.
>>
>> 1.pem
>>
>> Exporting new REQUEST ...
>>
>> Exporting all necessary objects.
>>
>> 256.spkac
>>
>> 512.spkac
>>
>> Exporting renew REQUEST ...
>>
>> Exporting all necessary objects.
>>
>> 256.spkac
>>
>> 512.spkac
>>
>> Exporting pending REQUEST ...
>>
>> Exporting all necessary objects.
>>
>> 256.spkac
>>
>> 512.spkac
>>
>> Exporting signed REQUEST ...
>>
>> Exporting all necessary objects.
>>
>> 256.spkac
>>
>> 512.spkac
>>
>> Exporting approved REQUEST ...
>>
>> Exporting all necessary objects.
>>
>> 256.spkac
>>
>> 512.spkac
>>
>> Exporting archived REQUEST ...
>>
>> Exporting all necessary objects.
>>
>> 256.spkac
>>
>> 512.spkac
>>
>> Exporting deleted REQUEST ...
>>
>> Exporting all necessary objects.
>>
>> 256.spkac
>>
>> 512.spkac
>>
>> Exporting valid CERTIFICATE ...
>>
>> Exporting all necessary objects.
>>
>> 998806535358870519861744.pem
>>
>> 419063751874877379914325.pem
>>
>> Exporting expired CERTIFICATE ...
>>
>> Exporting all necessary objects.
>>
>> 998806535358870519861744.pem
>>
>> 419063751874877379914325.pem
>>
>> Exporting revoked CERTIFICATE ...
>>
>> Exporting all necessary objects.
>>
>> 998806535358870519861744.pem
>>
>> 419063751874877379914325.pem
>>
>> Exporting suspended CERTIFICATE ...
>>
>> Exporting all necessary objects.
>>
>> 998806535358870519861744.pem
>>
>> 419063751874877379914325.pem
>>
>> Exporting archive ...
>>
>> Load required variables ...
>>
>> Changing to directory /home/openca/OpenCA/var/openca/tmp/tmp_19420 ...
>>
>> Running the export command(s) ...
>>
>> /bin/tar -cvpf /tmp/openca_local -C /home/openca/OpenCA/var/openca/tmp/tmp_19420 .
>>
>> Archive created successfully.
>>
>> Test the archive ...
>>
>> /bin/tar -tvf /tmp/openca_local
>>
>> Clean up ...Ok.
>>
>>
>>
>>
>> Nicolás Macia
>> _____________
>> CERTunlp
>>
>> El 27/02/14 21:48, Nicolas Macia escribió:
>>> Hello, I have a problem.
>>>
>>> After requesting Digital Cert at public site, an URL is sent to the
>>> requester to confirm his email address
>>>
>>> The problem is what it is seen at RA interface:
>>> - CSR confirmed using previous URL are tagged with state NEW
>>> - CSR not confirmed are tagged with state TEMPNEW
>>> - Approved CSR are tagged with state APPROVED
>>>
>>> When I use the node interface to exchange information to the CA, all CSR of ANY STATE are exported to CA as approved REQUESTS.
>>>
>>> Seems to me that the problem is that RA only should export approved
>>> requests but it doesn't. 
>>>
>>> anyone who knows what is the problem here??
>>>
>>>
>>> Thanks
>>> Nico
>>
>>
>>
>> -----
>> CeSPI 
>> Centro Superior para el Procesamiento de la Información
>>
>> Universidad Nacional de La Plata
>> -------------------------------------------------------------------------------
>> Proteja el Medioambiente. No imprima este mail si no es absolutamente necesario
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> Customize your own dashboards, set traffic alerts and generate reports.
>> Network behavioral analysis & security monitoring. All-in-one tool.
>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> OpenCA-Devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openca-devel
>
>



-----
CeSPI 
Centro Superior para el Procesamiento de la Información

Universidad Nacional de La Plata
-------------------------------------------------------------------------------
Proteja el Medioambiente. No imprima este mail si no es absolutamente necesario

Hello Nicolas,

I think you were looking at the right place. The function exportDB in 
export-import.lib
holds a list of states which shall be exported. TEMPNEW is not among the 
ones to
be exported, so these requests which are not validated should not even 
leave the
RA. Nevertheless, it would make sense to handle TEMPNEW in importObjects
just in case. However, all other states should already be handled 
correctly, at least
for Openca-base 1.5.1. In the output below I can't see any export of a 
request.
Could you try to export the data base with requests of different states 
( TEMPNEW /
NEW / APPROVED ) and check the tar file how they are written to the device?

best regards,
Martin

PS: I'm suggesting the attached patch to make sure the TEMPNEW state is 
correctly
handled during import

On 02/28/2014 03:35 PM, Nicolas Macia (CeSPI) wrote:
> I left to say that this behavior happend on:
> - Openca-base 1.5.1 / Openca-tools 1.3.0 on Debian 7 (Stable)
> - Openca-base 1.1.1 / Openca-tools 1.3.0 on Debian 6 (Old Stable)
>
> I think that this problem could be related with another bug related with
> putting all objects (CA CERT / CERTIFICATE / REQUEST) in all different
> categories regardless their status: CACERT [valid / expired] , REQUEST
> [new / renew / pending / signed / approved / archived / deleted] ,
> CERTIFICATE [valid / expired / revoked / suspended]
>
> For example, on OpenCA 1.5.1 on my CA that have:
> - one CA cert
> - one CRL
> - two valid certificates
>
> if I make on the node interface:
> Node Ops -> Backup and Recovery -> Database
>
> I can see the following:
>
> Thursday 27 February 21:48:13 UTC
> Exporting DB ...
> Please wait until operation completes
> Exporting valid CA_CERTIFICATE ...
>
> Exporting all necessary objects.
>
> cc2821c7d9025aadb34c467ea115980f3e64690b.pem
>
> Exporting expired CA_CERTIFICATE ...
>
> Exporting all necessary objects.
>
> cc2821c7d9025aadb34c467ea115980f3e64690b.pem
>
> Exporting new CRR ...
>
> No objects are present.
>
> Exporting pending CRR ...
>
> No objects are present.
>
> Exporting signed CRR ...
>
> No objects are present.
>
> Exporting approved CRR ...
>
> No objects are present.
>
> Exporting archived CRR ...
>
> No objects are present.
>
> Exporting deleted CRR ...
>
> No objects are present.
>
> Exporting valid CRL ...
>
> Exporting all necessary objects.
>
> 1.pem
>
> Exporting new REQUEST ...
>
> Exporting all necessary objects.
>
> 256.spkac
>
> 512.spkac
>
> Exporting renew REQUEST ...
>
> Exporting all necessary objects.
>
> 256.spkac
>
> 512.spkac
>
> Exporting pending REQUEST ...
>
> Exporting all necessary objects.
>
> 256.spkac
>
> 512.spkac
>
> Exporting signed REQUEST ...
>
> Exporting all necessary objects.
>
> 256.spkac
>
> 512.spkac
>
> Exporting approved REQUEST ...
>
> Exporting all necessary objects.
>
> 256.spkac
>
> 512.spkac
>
> Exporting archived REQUEST ...
>
> Exporting all necessary objects.
>
> 256.spkac
>
> 512.spkac
>
> Exporting deleted REQUEST ...
>
> Exporting all necessary objects.
>
> 256.spkac
>
> 512.spkac
>
> Exporting valid CERTIFICATE ...
>
> Exporting all necessary objects.
>
> 998806535358870519861744.pem
>
> 419063751874877379914325.pem
>
> Exporting expired CERTIFICATE ...
>
> Exporting all necessary objects.
>
> 998806535358870519861744.pem
>
> 419063751874877379914325.pem
>
> Exporting revoked CERTIFICATE ...
>
> Exporting all necessary objects.
>
> 998806535358870519861744.pem
>
> 419063751874877379914325.pem
>
> Exporting suspended CERTIFICATE ...
>
> Exporting all necessary objects.
>
> 998806535358870519861744.pem
>
> 419063751874877379914325.pem
>
> Exporting archive ...
>
> Load required variables ...
>
> Changing to directory /home/openca/OpenCA/var/openca/tmp/tmp_19420 ...
>
> Running the export command(s) ...
>
> /bin/tar -cvpf /tmp/openca_local -C /home/openca/OpenCA/var/openca/tmp/tmp_19420 .
>
> Archive created successfully.
>
> Test the archive ...
>
> /bin/tar -tvf /tmp/openca_local
>
> Clean up ...Ok.
>
>
>
>
> Nicolás Macia
> _____________
> CERTunlp
>
> El 27/02/14 21:48, Nicolas Macia escribió:
>> Hello, I have a problem.
>>
>> After requesting Digital Cert at public site, an URL is sent to the
>> requester to confirm his email address
>>
>> The problem is what it is seen at RA interface:
>> - CSR confirmed using previous URL are tagged with state NEW
>> - CSR not confirmed are tagged with state TEMPNEW
>> - Approved CSR are tagged with state APPROVED
>>
>> When I use the node interface to exchange information to the CA, all CSR of ANY STATE are exported to CA as approved REQUESTS.
>>
>> Seems to me that the problem is that RA only should export approved
>> requests but it doesn't.
>>
>> anyone who knows what is the problem here??
>>
>>
>> Thanks
>> Nico
>
>
>
>
> -----
> CeSPI
> Centro Superior para el Procesamiento de la Información
>
> Universidad Nacional de La Plata
> -------------------------------------------------------------------------------
> Proteja el Medioambiente. No imprima este mail si no es absolutamente necesario
>
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> OpenCA-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openca-devel

I left to say that this behavior happend on:
- Openca-base 1.5.1 / Openca-tools 1.3.0 on Debian 7 (Stable)
- Openca-base 1.1.1 / Openca-tools 1.3.0 on Debian 6 (Old Stable)

I think that this problem could be related with another bug related with
putting all objects (CA CERT / CERTIFICATE / REQUEST) in all different
categories regardless their status: CACERT [valid / expired] , REQUEST
[new / renew / pending / signed / approved / archived / deleted] ,
CERTIFICATE [valid / expired / revoked / suspended]

For example, on OpenCA 1.5.1 on my CA that have:
- one CA cert
- one CRL
- two valid certificates

if I make on the node interface:
Node Ops -> Backup and Recovery -> Database

I can see the following:

Thursday 27 February 21:48:13 UTC
Exporting DB ...
Please wait until operation completes
Exporting valid CA_CERTIFICATE ...

Exporting all necessary objects.

cc2821c7d9025aadb34c467ea115980f3e64690b.pem

Exporting expired CA_CERTIFICATE ...

Exporting all necessary objects.

cc2821c7d9025aadb34c467ea115980f3e64690b.pem

Exporting new CRR ...

No objects are present.

Exporting pending CRR ...

No objects are present.

Exporting signed CRR ...

No objects are present.

Exporting approved CRR ...

No objects are present.

Exporting archived CRR ...

No objects are present.

Exporting deleted CRR ...

No objects are present.

Exporting valid CRL ...

Exporting all necessary objects.

1.pem

Exporting new REQUEST ...

Exporting all necessary objects.

256.spkac

512.spkac

Exporting renew REQUEST ...

Exporting all necessary objects.

256.spkac

512.spkac

Exporting pending REQUEST ...

Exporting all necessary objects.

256.spkac

512.spkac

Exporting signed REQUEST ...

Exporting all necessary objects.

256.spkac

512.spkac

Exporting approved REQUEST ...

Exporting all necessary objects.

256.spkac

512.spkac

Exporting archived REQUEST ...

Exporting all necessary objects.

256.spkac

512.spkac

Exporting deleted REQUEST ...

Exporting all necessary objects.

256.spkac

512.spkac

Exporting valid CERTIFICATE ...

Exporting all necessary objects.

998806535358870519861744.pem

419063751874877379914325.pem

Exporting expired CERTIFICATE ...

Exporting all necessary objects.

998806535358870519861744.pem

419063751874877379914325.pem

Exporting revoked CERTIFICATE ...

Exporting all necessary objects.

998806535358870519861744.pem

419063751874877379914325.pem

Exporting suspended CERTIFICATE ...

Exporting all necessary objects.

998806535358870519861744.pem

419063751874877379914325.pem

Exporting archive ...

Load required variables ...

Changing to directory /home/openca/OpenCA/var/openca/tmp/tmp_19420 ...

Running the export command(s) ...

/bin/tar -cvpf /tmp/openca_local -C /home/openca/OpenCA/var/openca/tmp/tmp_19420 .

Archive created successfully.

Test the archive ...

/bin/tar -tvf /tmp/openca_local

Clean up ...Ok.




Nicolás Macia
_____________
CERTunlp

El 27/02/14 21:48, Nicolas Macia escribió:
> Hello, I have a problem.
>
> After requesting Digital Cert at public site, an URL is sent to the
> requester to confirm his email address
>
> The problem is what it is seen at RA interface:
> - CSR confirmed using previous URL are tagged with state NEW
> - CSR not confirmed are tagged with state TEMPNEW
> - Approved CSR are tagged with state APPROVED
>
> When I use the node interface to exchange information to the CA, all CSR of ANY STATE are exported to CA as approved REQUESTS.
>
> Seems to me that the problem is that RA only should export approved
> requests but it doesn't. 
>
> anyone who knows what is the problem here??
>
>
> Thanks
> Nico





-----
CeSPI 
Centro Superior para el Procesamiento de la Información

Universidad Nacional de La Plata
-------------------------------------------------------------------------------
Proteja el Medioambiente. No imprima este mail si no es absolutamente necesario

Hello, I have a problem.

After requesting Digital Cert at public site, an URL is sent to the
requester to confirm his email address

The problem is what it is seen at RA interface:
- CSR confirmed using previous URL are tagged with state NEW
- CSR not confirmed are tagged with state TEMPNEW
- Approved CSR are tagged with state APPROVED

When I use the node interface to exchange information to the CA, all CSR of ANY STATE are exported to CA as approved REQUESTS.

Seems to me that the problem is that RA only should export approved
requests but it doesn't. 

anyone who knows what is the problem here??


Thanks
Nico
-----
CeSPI 
Centro Superior para el Procesamiento de la Información

Universidad Nacional de La Plata
-------------------------------------------------------------------------------
Proteja el Medioambiente. No imprima este mail si no es absolutamente necesario

Hi,

I have found a minor bug in OpenCA 1.5.x

the following templates:
src/common/lib/mails/*/verifyMail.msg 

contain MIME multipart messages which ask the user to confirm his email
address. The boundary between the alternatives is defined at the
beginning of each file as "----=OpenCA_Verify_Email_@$$@" and each new
part begins with such a boundary prepended by two hyphens:
--boundary
which is correct (there are six hyphens, then), but the whole message
should be closed by the encapsulation
--boundary--
instead of
--boundary
(the two trailing hyphens in the closing encapsulation boundary are
missing for all languages).
see http://en.wikipedia.org/wiki/MIME#Multipart_messages or
http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

Some mail clients (e.g. Thunderbird) show the message correctly, but
some others (Macintosh) display an empty message (which makes it
difficult to click on the link).

Also, I believe the intention is that @$$@ should be replaced by some
PID or so, which actually doesn't happen
I believe the characters @ and $ which remain in the boundary also are
not fully standard conform if you look at the ones explicitly given in
rfc1341 (although it simply speaks about "characters from a set of
characters known to be very robust through email gateways"... ). One
could simply drop this part of the boundary or we would need an
appropriate replacement rule in sub libSendEmailVerifyMessage in
src/common/lib/functions/mail-utils.lib:
                $txt = $query->subVar( $txt, '@$$@', $$ );
but isn't this anyway always the same PID until the server admin
restarts the openca daemon?

best regards,
Martin

Already installed? Change config.xml. Otherwise use compile options. 

Dave


----- Original Message -----
From: Miguel Angel Robledo [mar...@sa...]
Sent: 12/19/2013 01:08 PM ZW3
To: "Users' Help and Suggestions" <ope...@li...>; ope...@li...
Subject: [OpenCA-Devel] Change URL prefix



Hi,

I need to change the default url prefix for htdocs and cgi because i 
need a same parent directory, for example /pki/htdocs and /pki/cgi-bin. 
Is it possible?

Can any help me?

-- 
Ing. Miguel Angel Robledo
Infraestructura de Firma Digital
Secretaría de Tecnologías para la Gestión
Ministerio de Gobierno y Reforma del Estado
Provincia de Santa Fe
San Martín 2466 3° Piso (S3000FSB) Santa Fe
+54 342 4508700/4574891 int 5132


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
OpenCA-Devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-devel

Hi,

I need to change the default url prefix for htdocs and cgi because i 
need a same parent directory, for example /pki/htdocs and /pki/cgi-bin. 
Is it possible?

Can any help me?

-- 
Ing. Miguel Angel Robledo
Infraestructura de Firma Digital
Secretaría de Tecnologías para la Gestión
Ministerio de Gobierno y Reforma del Estado
Provincia de Santa Fe
San Martín 2466 3° Piso (S3000FSB) Santa Fe
+54 342 4508700/4574891 int 5132

Hi Dave,

I'm a little bit confused.
I assume the term "OpenCA installation point" means one of the directories I configure with
"--with-openca-prefix" or "--with-module-prefix".
No, it is not there. I updated my find database and "locate DB.pm" only gives:
	/usr/lib/perl5/5.16.0/DB.pm
Why should it be at the OpenCA installation point, if I did not make "make install-something"
up to now?
I'm just before the point to install something, I'm at the point to get "make test" working.

I'm not familiar with how perl sources are organized. I expect some source directory for building
OpenCA/DB.pm, but am not able to find it.

I don't want to pollute this mailinglist with my stupidness. We should switch to personal conversation
if you think I do so...

hd^2


On Tue, 17 Dec 2013 23:40:44 +0100, <bla...@gd...> wrote:

> Hi Hans
>
> First check to make sure DB.pm exists under your OpenCA installation point. Second the permissions should be 755. It also should be owned by openca user.
>
> Dave
>
>
> ----- Original Message -----
> From: "Hans-Dieter Doll" [Han...@dr...]
> Sent: 12/17/2013 11:29 PM CET
> To: "OpenCA Developers" <ope...@li...>; David Blaine
> Subject: Re: [OpenCA-Devel] Test fails with OpenCA 1.5.0 on openSUSE 12.2
>
>
>
> I managed to solve nearly all my problems by inserting our() statements and putting quotes
> around some BareWords in src/common/lib/cmds/*. See attachment (refers to 1.5.1 tarball).
>
> The only remaining problem is:
> Can't locate OpenCA/DB.pm in @INC (@INC contains: ../../../modules/openca-xml-cache/blib/lib ../../../modules/openca-x509/blib/lib ../../../modules/openca-user/blib/lib ../../../modules/openca-ui-html/blib/lib ../../../modules/openca-tristatecgi/blib/lib ../../../modules/openca-tools/blib/lib ../../../modules/openca-statemachine/blib/lib ../../../modules/openca-session/blib/lib ../../../modules/openca-req/blib/lib ../../../modules/openca-pkcs7/blib/lib ../../../modules/openca-openssl/blib/lib ../../../modules/openca-log/blib/lib ../../../modules/openca-ldap/blib/lib ../../../modules/openca-dbi/blib/lib ../../../modules/openca-crypto/blib/lib ../../../modules/openca-crl/blib/lib ../../../modules/openca-configuration/blib/lib ../../../modules/openca-ac/blib/lib ../../../modules/openca-ac/blib/lib ../../../modules/openca-configuration/blib/lib ../../../modules/openca-crl/blib/lib ../../../modules/openca-crypto/blib/lib ../../../modules/openca-dbi/blib/lib
> ../../../modules/openca-ldap/blib/lib ../../../modules/openca-log/blib/lib ../../../modules/openca-openssl/blib/lib ../../../modules/openca-pkcs7/blib/lib ../../../modules/openca-req/blib/lib ../../../modules/openca-session/blib/lib ../../../modules/openca-statemachine/blib/lib ../../../modules/openca-tools/blib/lib ../../../modules/openca-tristatecgi/blib/lib ../../../modules/openca-ui-html/blib/lib ../../../modules/openca-user/blib/lib ../../../modules/openca-x509/blib/lib ../../../modules/openca-xml-cache/blib/lib ../../../modules/openca-ac/blib/arch ../../../modules/openca-configuration/blib/arch ../../../modules/openca-crl/blib/arch ../../../modules/openca-crypto/blib/arch ../../../modules/openca-dbi/blib/arch ../../../modules/openca-ldap/blib/arch ../../../modules/openca-log/blib/arch ../../../modules/openca-openssl/blib/arch ../../../modules/openca-pkcs7/blib/arch ../../../modules/openca-req/blib/arch ../../../modules/openca-session/blib/arch
> ../../../modules/openca-statemachine/blib/arch ../../../modules/openca-tools/blib/arch ../../../modules/openca-tristatecgi/blib/arch ../../../modules/openca-ui-html/blib/arch ../../../modules/openca-user/blib/arch ../../../modules/openca-x509/blib/arch ../../../modules/openca-xml-cache/blib/arch /usr/lib/perl5/site_perl/5.16.0/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.16.0 /usr/lib/perl5/vendor_perl/5.16.0/i586-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.0 /usr/lib/perl5/5.16.0/i586-linux-thread-multi /usr/lib/perl5/5.16.0 /usr/lib/perl5/site_perl/5.16.0/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.16.0 /usr/lib/perl5/site_perl .) at initDB line 3.
> BEGIN failed--compilation aborted at initDB line 3.
>
> Any hints?
>
> hd^2
>
> On Tue, 17 Dec 2013 18:50:08 +0100, Hans-Dieter Doll <Han...@dr...> wrote:
>
>> Hi,
>>
>> 1.5.1 has same problems. What seems to help is to insert our() statements like here:
>>
>> =====================================================================
>> diff -Naur cmds.orig/advanced_csr cmds/advanced_csr
>> --- cmds.orig/advanced_csr      2011-02-14 22:45:41.000000000 +0100
>> +++ cmds/advanced_csr   2013-12-17 17:25:19.585667892 +0100
>> @@ -701,6 +701,7 @@
>>
>>   if ( ($STATUS eq "" ) or ( $query->param('status') eq "finished-client-filled-form") ) {
>>
>> +       our ($DEBUG);
>>           my $dn = $query->param('dn');
>>           my $keytype = $query->param('keytype');
>>
>> diff -Naur cmds.orig/authenticated_csr cmds/authenticated_csr
>> --- cmds.orig/authenticated_csr 2011-02-14 22:45:41.000000000 +0100
>> +++ cmds/authenticated_csr      2013-12-17 17:30:28.564947105 +0100
>> @@ -1238,6 +1238,8 @@
>>   }
>>
>>   sub checkLogin {
>> +       our ($query, $errval);
>> +
>>          my $reqTwig = shift;
>>
>>          my $username = $query->param('LOGIN_ATTRIBUTE_LOGIN');
>>
>> =====================================================================
>>
>> and so on...
>>
>> As I'm not a perl programmer, I do not really know what I'm doing.
>> I simply guess that our() is required to access a global Variable.
>> Maybe my perl version (v5.16.0) is more strict than the version you are using?
>>
>> I will continue inserting our() statements until "make test" passes ok.
>> If I'm on the wrong way or someone knows a less tedious solution,
>> please let me know...
>>
>> hd^2
>>
>> On Fri, 13 Dec 2013 23:42:42 +0100, <bla...@gd...> wrote:
>>
>>> Download and compile 1.5.1 from ftp.openca.org.
>>>
>>> Dave
>>>
>>>
>>> ----- Original Message -----
>>> From: "Hans-Dieter Doll" [Han...@dr...]
>>> Sent: 12/13/2013 11:02 PM CET
>>> To: ope...@li...
>>> Subject: [OpenCA-Devel] Test fails with OpenCA 1.5.0 on openSUSE 12.2
>>>
>>>
>>>
>>> Hi,
>>>
>>> I just now downloaded openca-tools-1.3.0 and openca-base-1.5.0 on my openSUSE 12.2 (i386).
>>> The Perl modules stated in the installation guide are all of a much newer revision.
>>>
>>> The tools were installed without any problems at standard places (no configure option given).
>>> The base compiled successful with the following configure options:
>>> ./configure --with-openca-user=openca --with-openca-group=openca \
>>>          --with-module-prefix=/home/openca/perl \
>>>          --with-openca-prefix=/home/openca \
>>>          --with-web-host=hd2pc2.drb.insel.de \
>>>          --with-httpd-user=wwwrun --with-httpd-group=www \
>>>          --with-httpd-fs-prefix=/usr/share/apache2 \
>>>          --with-cgi-fs-prefix=/srv/www/cgi-bin \
>>>          --with-htdocs-fs-prefix=/srv/www/htdocs
>>>
>>> But "make test" gives dozens of errors, which look all very similar.
>>> Some examples:
>>>
>>> Global symbol "$DEBUG" requires explicit package name at advanced_csr line 815.
>>> advanced_csr had compilation errors.
>>> Variable "$query" is not imported at authenticated_csr line 1243.
>>> Variable "$query" is not imported at authenticated_csr line 1244.
>>> Variable "$query" is not imported at authenticated_csr line 1245.
>>> Variable "$errval" is not imported at authenticated_csr line 1250.
>>> Variable "$errval" is not imported at authenticated_csr line 1253.
>>> Variable "$errval" is not imported at authenticated_csr line 1262.
>>> Variable "$errval" is not imported at authenticated_csr line 1266.
>>> Global symbol "$query" requires explicit package name at authenticated_csr line 1243.
>>> Global symbol "$query" requires explicit package name at authenticated_csr line 1244.
>>> Global symbol "$query" requires explicit package name at authenticated_csr line 1245.
>>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1250.
>>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1253.
>>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1262.
>>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1266.
>>> authenticated_csr had compilation errors.
>>> [...]
>>> Global symbol "$cryptoShell" requires explicit package name at crlList line 32.
>>> crlList had compilation errors.
>>> [...]
>>> Variable "$query" is not imported at genCACert line 194.
>>> Variable "$query" is not imported at genCACert line 200.
>>> Global symbol "$query" requires explicit package name at genCACert line 194.
>>> Global symbol "$query" requires explicit package name at genCACert line 200.
>>> genCACert had compilation errors.
>>>
>>> And so on...
>>>
>>> Unfortunately I'm not a perl programmer and have no idea, what's going on here.
>>> Any hints?
>>>
>>> hd^2
>>>
>>
>>
>
>
> --
> Hans-Dieter Doll
> Dr. Brunthaler Industrielle Informationstechnik GmbH
> Motzstr. 5, D-10777 Berlin
> Fon: +49.30.215081-0, Fax: +49.30.215081-88
> mailto:Hans-Dieter.Doll@DrB.Insel.DE
> http://www.brunthaler.de
>
> Geschäftsführer:       Prof. Dr.-Ing. Stefan Brunthaler
> Sitz der Gesellschaft: Berlin
> Handelsregister:       HRB 27 337 Amtsgericht Charlottenburg
> --
> Wir sind Mitglied des inilog Netzwerks - www.inilog.de


-- 
Hans-Dieter Doll
Dr. Brunthaler Industrielle Informationstechnik GmbH
Motzstr. 5, D-10777 Berlin
Fon: +49.30.215081-0, Fax: +49.30.215081-88
mailto:Hans-Dieter.Doll@DrB.Insel.DE
http://www.brunthaler.de

Geschäftsführer:       Prof. Dr.-Ing. Stefan Brunthaler
Sitz der Gesellschaft: Berlin
Handelsregister:       HRB 27 337 Amtsgericht Charlottenburg
--
Wir sind Mitglied des inilog Netzwerks - www.inilog.de

Hi Hans

First check to make sure DB.pm exists under your OpenCA installation point. Second the permissions should be 755. It also should be owned by openca user. 

Dave


----- Original Message -----
From: "Hans-Dieter Doll" [Han...@dr...]
Sent: 12/17/2013 11:29 PM CET
To: "OpenCA Developers" <ope...@li...>; David Blaine
Subject: Re: [OpenCA-Devel] Test fails with OpenCA 1.5.0 on openSUSE 12.2



I managed to solve nearly all my problems by inserting our() statements and putting quotes
around some BareWords in src/common/lib/cmds/*. See attachment (refers to 1.5.1 tarball).

The only remaining problem is:
Can't locate OpenCA/DB.pm in @INC (@INC contains: ../../../modules/openca-xml-cache/blib/lib ../../../modules/openca-x509/blib/lib ../../../modules/openca-user/blib/lib ../../../modules/openca-ui-html/blib/lib ../../../modules/openca-tristatecgi/blib/lib ../../../modules/openca-tools/blib/lib ../../../modules/openca-statemachine/blib/lib ../../../modules/openca-session/blib/lib ../../../modules/openca-req/blib/lib ../../../modules/openca-pkcs7/blib/lib ../../../modules/openca-openssl/blib/lib ../../../modules/openca-log/blib/lib ../../../modules/openca-ldap/blib/lib ../../../modules/openca-dbi/blib/lib ../../../modules/openca-crypto/blib/lib ../../../modules/openca-crl/blib/lib ../../../modules/openca-configuration/blib/lib ../../../modules/openca-ac/blib/lib ../../../modules/openca-ac/blib/lib ../../../modules/openca-configuration/blib/lib ../../../modules/openca-crl/blib/lib ../../../modules/openca-crypto/blib/lib ../../../modules/openca-dbi/blib/lib  
../../../modules/openca-ldap/blib/lib ../../../modules/openca-log/blib/lib ../../../modules/openca-openssl/blib/lib ../../../modules/openca-pkcs7/blib/lib ../../../modules/openca-req/blib/lib ../../../modules/openca-session/blib/lib ../../../modules/openca-statemachine/blib/lib ../../../modules/openca-tools/blib/lib ../../../modules/openca-tristatecgi/blib/lib ../../../modules/openca-ui-html/blib/lib ../../../modules/openca-user/blib/lib ../../../modules/openca-x509/blib/lib ../../../modules/openca-xml-cache/blib/lib ../../../modules/openca-ac/blib/arch ../../../modules/openca-configuration/blib/arch ../../../modules/openca-crl/blib/arch ../../../modules/openca-crypto/blib/arch ../../../modules/openca-dbi/blib/arch ../../../modules/openca-ldap/blib/arch ../../../modules/openca-log/blib/arch ../../../modules/openca-openssl/blib/arch ../../../modules/openca-pkcs7/blib/arch ../../../modules/openca-req/blib/arch ../../../modules/openca-session/blib/arch  
../../../modules/openca-statemachine/blib/arch ../../../modules/openca-tools/blib/arch ../../../modules/openca-tristatecgi/blib/arch ../../../modules/openca-ui-html/blib/arch ../../../modules/openca-user/blib/arch ../../../modules/openca-x509/blib/arch ../../../modules/openca-xml-cache/blib/arch /usr/lib/perl5/site_perl/5.16.0/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.16.0 /usr/lib/perl5/vendor_perl/5.16.0/i586-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.0 /usr/lib/perl5/5.16.0/i586-linux-thread-multi /usr/lib/perl5/5.16.0 /usr/lib/perl5/site_perl/5.16.0/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.16.0 /usr/lib/perl5/site_perl .) at initDB line 3.
BEGIN failed--compilation aborted at initDB line 3.

Any hints?

hd^2

On Tue, 17 Dec 2013 18:50:08 +0100, Hans-Dieter Doll <Han...@dr...> wrote:

> Hi,
>
> 1.5.1 has same problems. What seems to help is to insert our() statements like here:
>
> =====================================================================
> diff -Naur cmds.orig/advanced_csr cmds/advanced_csr
> --- cmds.orig/advanced_csr      2011-02-14 22:45:41.000000000 +0100
> +++ cmds/advanced_csr   2013-12-17 17:25:19.585667892 +0100
> @@ -701,6 +701,7 @@
>
>   if ( ($STATUS eq "" ) or ( $query->param('status') eq "finished-client-filled-form") ) {
>
> +       our ($DEBUG);
>           my $dn = $query->param('dn');
>           my $keytype = $query->param('keytype');
>
> diff -Naur cmds.orig/authenticated_csr cmds/authenticated_csr
> --- cmds.orig/authenticated_csr 2011-02-14 22:45:41.000000000 +0100
> +++ cmds/authenticated_csr      2013-12-17 17:30:28.564947105 +0100
> @@ -1238,6 +1238,8 @@
>   }
>
>   sub checkLogin {
> +       our ($query, $errval);
> +
>          my $reqTwig = shift;
>
>          my $username = $query->param('LOGIN_ATTRIBUTE_LOGIN');
>
> =====================================================================
>
> and so on...
>
> As I'm not a perl programmer, I do not really know what I'm doing.
> I simply guess that our() is required to access a global Variable.
> Maybe my perl version (v5.16.0) is more strict than the version you are using?
>
> I will continue inserting our() statements until "make test" passes ok.
> If I'm on the wrong way or someone knows a less tedious solution,
> please let me know...
>
> hd^2
>
> On Fri, 13 Dec 2013 23:42:42 +0100, <bla...@gd...> wrote:
>
>> Download and compile 1.5.1 from ftp.openca.org.
>>
>> Dave
>>
>>
>> ----- Original Message -----
>> From: "Hans-Dieter Doll" [Han...@dr...]
>> Sent: 12/13/2013 11:02 PM CET
>> To: ope...@li...
>> Subject: [OpenCA-Devel] Test fails with OpenCA 1.5.0 on openSUSE 12.2
>>
>>
>>
>> Hi,
>>
>> I just now downloaded openca-tools-1.3.0 and openca-base-1.5.0 on my openSUSE 12.2 (i386).
>> The Perl modules stated in the installation guide are all of a much newer revision.
>>
>> The tools were installed without any problems at standard places (no configure option given).
>> The base compiled successful with the following configure options:
>> ./configure --with-openca-user=openca --with-openca-group=openca \
>>          --with-module-prefix=/home/openca/perl \
>>          --with-openca-prefix=/home/openca \
>>          --with-web-host=hd2pc2.drb.insel.de \
>>          --with-httpd-user=wwwrun --with-httpd-group=www \
>>          --with-httpd-fs-prefix=/usr/share/apache2 \
>>          --with-cgi-fs-prefix=/srv/www/cgi-bin \
>>          --with-htdocs-fs-prefix=/srv/www/htdocs
>>
>> But "make test" gives dozens of errors, which look all very similar.
>> Some examples:
>>
>> Global symbol "$DEBUG" requires explicit package name at advanced_csr line 815.
>> advanced_csr had compilation errors.
>> Variable "$query" is not imported at authenticated_csr line 1243.
>> Variable "$query" is not imported at authenticated_csr line 1244.
>> Variable "$query" is not imported at authenticated_csr line 1245.
>> Variable "$errval" is not imported at authenticated_csr line 1250.
>> Variable "$errval" is not imported at authenticated_csr line 1253.
>> Variable "$errval" is not imported at authenticated_csr line 1262.
>> Variable "$errval" is not imported at authenticated_csr line 1266.
>> Global symbol "$query" requires explicit package name at authenticated_csr line 1243.
>> Global symbol "$query" requires explicit package name at authenticated_csr line 1244.
>> Global symbol "$query" requires explicit package name at authenticated_csr line 1245.
>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1250.
>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1253.
>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1262.
>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1266.
>> authenticated_csr had compilation errors.
>> [...]
>> Global symbol "$cryptoShell" requires explicit package name at crlList line 32.
>> crlList had compilation errors.
>> [...]
>> Variable "$query" is not imported at genCACert line 194.
>> Variable "$query" is not imported at genCACert line 200.
>> Global symbol "$query" requires explicit package name at genCACert line 194.
>> Global symbol "$query" requires explicit package name at genCACert line 200.
>> genCACert had compilation errors.
>>
>> And so on...
>>
>> Unfortunately I'm not a perl programmer and have no idea, what's going on here.
>> Any hints?
>>
>> hd^2
>>
>
>


-- 
Hans-Dieter Doll
Dr. Brunthaler Industrielle Informationstechnik GmbH
Motzstr. 5, D-10777 Berlin
Fon: +49.30.215081-0, Fax: +49.30.215081-88
mailto:Hans-Dieter.Doll@DrB.Insel.DE
http://www.brunthaler.de

Geschäftsführer:       Prof. Dr.-Ing. Stefan Brunthaler
Sitz der Gesellschaft: Berlin
Handelsregister:       HRB 27 337 Amtsgericht Charlottenburg
--
Wir sind Mitglied des inilog Netzwerks - www.inilog.de

I managed to solve nearly all my problems by inserting our() statements and putting quotes
around some BareWords in src/common/lib/cmds/*. See attachment (refers to 1.5.1 tarball).

The only remaining problem is:
Can't locate OpenCA/DB.pm in @INC (@INC contains: ../../../modules/openca-xml-cache/blib/lib ../../../modules/openca-x509/blib/lib ../../../modules/openca-user/blib/lib ../../../modules/openca-ui-html/blib/lib ../../../modules/openca-tristatecgi/blib/lib ../../../modules/openca-tools/blib/lib ../../../modules/openca-statemachine/blib/lib ../../../modules/openca-session/blib/lib ../../../modules/openca-req/blib/lib ../../../modules/openca-pkcs7/blib/lib ../../../modules/openca-openssl/blib/lib ../../../modules/openca-log/blib/lib ../../../modules/openca-ldap/blib/lib ../../../modules/openca-dbi/blib/lib ../../../modules/openca-crypto/blib/lib ../../../modules/openca-crl/blib/lib ../../../modules/openca-configuration/blib/lib ../../../modules/openca-ac/blib/lib ../../../modules/openca-ac/blib/lib ../../../modules/openca-configuration/blib/lib ../../../modules/openca-crl/blib/lib ../../../modules/openca-crypto/blib/lib ../../../modules/openca-dbi/blib/lib  
../../../modules/openca-ldap/blib/lib ../../../modules/openca-log/blib/lib ../../../modules/openca-openssl/blib/lib ../../../modules/openca-pkcs7/blib/lib ../../../modules/openca-req/blib/lib ../../../modules/openca-session/blib/lib ../../../modules/openca-statemachine/blib/lib ../../../modules/openca-tools/blib/lib ../../../modules/openca-tristatecgi/blib/lib ../../../modules/openca-ui-html/blib/lib ../../../modules/openca-user/blib/lib ../../../modules/openca-x509/blib/lib ../../../modules/openca-xml-cache/blib/lib ../../../modules/openca-ac/blib/arch ../../../modules/openca-configuration/blib/arch ../../../modules/openca-crl/blib/arch ../../../modules/openca-crypto/blib/arch ../../../modules/openca-dbi/blib/arch ../../../modules/openca-ldap/blib/arch ../../../modules/openca-log/blib/arch ../../../modules/openca-openssl/blib/arch ../../../modules/openca-pkcs7/blib/arch ../../../modules/openca-req/blib/arch ../../../modules/openca-session/blib/arch  
../../../modules/openca-statemachine/blib/arch ../../../modules/openca-tools/blib/arch ../../../modules/openca-tristatecgi/blib/arch ../../../modules/openca-ui-html/blib/arch ../../../modules/openca-user/blib/arch ../../../modules/openca-x509/blib/arch ../../../modules/openca-xml-cache/blib/arch /usr/lib/perl5/site_perl/5.16.0/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.16.0 /usr/lib/perl5/vendor_perl/5.16.0/i586-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.0 /usr/lib/perl5/5.16.0/i586-linux-thread-multi /usr/lib/perl5/5.16.0 /usr/lib/perl5/site_perl/5.16.0/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.16.0 /usr/lib/perl5/site_perl .) at initDB line 3.
BEGIN failed--compilation aborted at initDB line 3.

Any hints?

hd^2

On Tue, 17 Dec 2013 18:50:08 +0100, Hans-Dieter Doll <Han...@dr...> wrote:

> Hi,
>
> 1.5.1 has same problems. What seems to help is to insert our() statements like here:
>
> =====================================================================
> diff -Naur cmds.orig/advanced_csr cmds/advanced_csr
> --- cmds.orig/advanced_csr      2011-02-14 22:45:41.000000000 +0100
> +++ cmds/advanced_csr   2013-12-17 17:25:19.585667892 +0100
> @@ -701,6 +701,7 @@
>
>   if ( ($STATUS eq "" ) or ( $query->param('status') eq "finished-client-filled-form") ) {
>
> +       our ($DEBUG);
>           my $dn = $query->param('dn');
>           my $keytype = $query->param('keytype');
>
> diff -Naur cmds.orig/authenticated_csr cmds/authenticated_csr
> --- cmds.orig/authenticated_csr 2011-02-14 22:45:41.000000000 +0100
> +++ cmds/authenticated_csr      2013-12-17 17:30:28.564947105 +0100
> @@ -1238,6 +1238,8 @@
>   }
>
>   sub checkLogin {
> +       our ($query, $errval);
> +
>          my $reqTwig = shift;
>
>          my $username = $query->param('LOGIN_ATTRIBUTE_LOGIN');
>
> =====================================================================
>
> and so on...
>
> As I'm not a perl programmer, I do not really know what I'm doing.
> I simply guess that our() is required to access a global Variable.
> Maybe my perl version (v5.16.0) is more strict than the version you are using?
>
> I will continue inserting our() statements until "make test" passes ok.
> If I'm on the wrong way or someone knows a less tedious solution,
> please let me know...
>
> hd^2
>
> On Fri, 13 Dec 2013 23:42:42 +0100, <bla...@gd...> wrote:
>
>> Download and compile 1.5.1 from ftp.openca.org.
>>
>> Dave
>>
>>
>> ----- Original Message -----
>> From: "Hans-Dieter Doll" [Han...@dr...]
>> Sent: 12/13/2013 11:02 PM CET
>> To: ope...@li...
>> Subject: [OpenCA-Devel] Test fails with OpenCA 1.5.0 on openSUSE 12.2
>>
>>
>>
>> Hi,
>>
>> I just now downloaded openca-tools-1.3.0 and openca-base-1.5.0 on my openSUSE 12.2 (i386).
>> The Perl modules stated in the installation guide are all of a much newer revision.
>>
>> The tools were installed without any problems at standard places (no configure option given).
>> The base compiled successful with the following configure options:
>> ./configure --with-openca-user=openca --with-openca-group=openca \
>>          --with-module-prefix=/home/openca/perl \
>>          --with-openca-prefix=/home/openca \
>>          --with-web-host=hd2pc2.drb.insel.de \
>>          --with-httpd-user=wwwrun --with-httpd-group=www \
>>          --with-httpd-fs-prefix=/usr/share/apache2 \
>>          --with-cgi-fs-prefix=/srv/www/cgi-bin \
>>          --with-htdocs-fs-prefix=/srv/www/htdocs
>>
>> But "make test" gives dozens of errors, which look all very similar.
>> Some examples:
>>
>> Global symbol "$DEBUG" requires explicit package name at advanced_csr line 815.
>> advanced_csr had compilation errors.
>> Variable "$query" is not imported at authenticated_csr line 1243.
>> Variable "$query" is not imported at authenticated_csr line 1244.
>> Variable "$query" is not imported at authenticated_csr line 1245.
>> Variable "$errval" is not imported at authenticated_csr line 1250.
>> Variable "$errval" is not imported at authenticated_csr line 1253.
>> Variable "$errval" is not imported at authenticated_csr line 1262.
>> Variable "$errval" is not imported at authenticated_csr line 1266.
>> Global symbol "$query" requires explicit package name at authenticated_csr line 1243.
>> Global symbol "$query" requires explicit package name at authenticated_csr line 1244.
>> Global symbol "$query" requires explicit package name at authenticated_csr line 1245.
>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1250.
>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1253.
>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1262.
>> Global symbol "$errval" requires explicit package name at authenticated_csr line 1266.
>> authenticated_csr had compilation errors.
>> [...]
>> Global symbol "$cryptoShell" requires explicit package name at crlList line 32.
>> crlList had compilation errors.
>> [...]
>> Variable "$query" is not imported at genCACert line 194.
>> Variable "$query" is not imported at genCACert line 200.
>> Global symbol "$query" requires explicit package name at genCACert line 194.
>> Global symbol "$query" requires explicit package name at genCACert line 200.
>> genCACert had compilation errors.
>>
>> And so on...
>>
>> Unfortunately I'm not a perl programmer and have no idea, what's going on here.
>> Any hints?
>>
>> hd^2
>>
>
>


-- 
Hans-Dieter Doll
Dr. Brunthaler Industrielle Informationstechnik GmbH
Motzstr. 5, D-10777 Berlin
Fon: +49.30.215081-0, Fax: +49.30.215081-88
mailto:Hans-Dieter.Doll@DrB.Insel.DE
http://www.brunthaler.de

Geschäftsführer:       Prof. Dr.-Ing. Stefan Brunthaler
Sitz der Gesellschaft: Berlin
Handelsregister:       HRB 27 337 Amtsgericht Charlottenburg
--
Wir sind Mitglied des inilog Netzwerks - www.inilog.de

Hi OpenCA Developers,

OpenCA 1.5.1 now supports email verification, but in some situations one
might want to issue a certificate even if the email address was not
verified (e.g. when the server-admin is sitting in the office next door
and has not yet set up all his mailing lists, but requests a server
certificate in advance)... I have added a menu point in our ca interface
and patched the commands dealing with the requests.
I'm not sure if I have caught all the places where the status of the
requests is checked. I'd propose to add this in future releases.
Comments and suggestions for improvements welcome.

best regards,
Martin