Looking at the code, it looks like the root cause was due to errors during my 
database upgrade. It appears that cert_key in both the crr and certificate 
tables should be decimal(60,0) for mysql. With that fix in place, everything 
now works correctly.


On 9/27/10 10:52 AM, "Administrator" <duane.dinsc...@teamaol.com> wrote:

Looks like real issue is bumping up against max bigint(20) size — 
9223372036854775807. At this point, I will have to either using a smaller 
serial ID or switch to unsigned bigint for now. OpenCA defaults to 
RANDOM_SERIAL_SIZE 10, which definitely will not work. Maybe I have a bad 
database upgrade from 1.0.1 to 1.1.0, my current certificate table reads:
mysql> describe certificate;
+-------------------+---------------------+------+-----+---------+----------------+
| Field             | Type                | Null | Key | Default | Extra        
  |
+-------------------+---------------------+------+-----+---------+----------------+
| cert_key          | bigint(20)          | NO   | PRI | NULL    |              
  |
| format            | text                | YES  |     | NULL    |              
  |
| data              | text                | YES  |     | NULL    |              
  |
| dn                | text                | YES  |     | NULL    |              
  |
| cn                | text                | YES  |     | NULL    |              
  |
| email             | text                | YES  |     | NULL    |              
  |
| status            | text                | YES  |     | NULL    |              
  |
| role              | text                | YES  |     | NULL    |              
  |
| public_key        | text                | YES  |     | NULL    |              
  |
| notafter          | bigint(20)          | YES  |     | NULL    |              
  |
| req_key           | bigint(20)          | YES  |     | NULL    |              
  |
| loa               | text                | YES  |     | NULL    |              
  |
| rowid             | bigint(20) unsigned | NO   | UNI | NULL    | 
auto_increment |
| notbefore         | bigint(20)          | YES  |     | NULL    |              
  |
| suspended_after   | bigint(20)          | YES  |     | NULL    |              
  |
| revoked_after     | bigint(20)          | YES  |     | NULL    |              
  |
| invalidity_reason | text                | YES  |     | NULL    |              
  |
| owner             | varchar(255)        | YES  |     | NULL    |              
  |
+-------------------+---------------------+------+-----+---------+----------------+
18 rows in set (0.00 sec)



On 9/27/10 9:38 AM, "Administrator" <duane.dinsc...@teamaol.com> wrote:

More details: This error occurs when I have ‘Auto Certificate Issuing’ turned 
on and the certificate is generated from the automation. I ran another one 
manually using the ‘Issue Certificate’ button and it worked correctly.


On 9/24/10 2:38 PM, "Administrator" <duane.dinsc...@teamaol.com> wrote:

Using RANDOM_SERIAL_SIZE of 8, OpenCA appears to generate a valid certificate 
with hex serial ID: 0xa3:f1:ed:4d:bf:06:30:8e. The proper decimal conversion of 
that value is 11813484215742640270, but the value of cert_key in the 
certificate table (using MySQL) is 9223372036854775807. When I try to use the 
GUI to view the certificate I get the error:
  [initServer:314] Cannot load certificate 11813484215742640270 from the 
database.

I suspect the GUI is doing the conversion the correct way, but whatever is 
loading the certificate into the database is generating the wrong value for 
cert_key. I get similar conversion errors if I generate other certs with other 
similarly sized random serial numbers. I do not get the error if my 
RANDOM_SERIAL_SIZE is small enough (i.e. 4). I’m using OpenCA 1.1.0, did I miss 
a patch somewhere that addresses this issue? I found the other patches on the 
OpenCA PKI Wiki site, but they don’t appear to help.

________________________________
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
________________________________
_______________________________________________
Openca-Users mailing list
Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users

________________________________
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
________________________________
_______________________________________________
Openca-Users mailing list
Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users

________________________________
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
________________________________
_______________________________________________
Openca-Users mailing list
Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Openca-Users mailing list
Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users

Reply via email to