Signing a CSR from JetDirect

Dean Gibson (System Administrator)

unread,

Jul 11, 2003, 7:55:06 PM7/11/03

to

We have an HP LJ 4600 with an internal JetDirect interface that provides an embedded web server for administration. The web server has the ability to generate a CSR (hplj.csr in the example below), which one can get signed and import the signed certificate back into the web server.

Since we feel that paying $$$ to a real CA to sign the CSR is a waste of money, we thought we'd just try to sign it ourselves, so I did:

openssl x509 -req -in hplj.csr -CA ultimeth.pem -days 3650 -set_serial 01 -out hplj.crt

where "ultimeth.pem" is a self-signed wildcard key/certificate previously generated by openssl and working fine in Apache, Postfix, and IMAP servers.

I then attempted to import (via cut-and-paste) the "hplj.crt" file back into the HP JetDirect web server, but it doesn't like it ("The certificate entered was invalid. Please try again and be sure to include the entire certificate correctly.").

Now, I suspect that this is because the HP JetDirect web server checks to see if the certificate was signed by other than a root CA.

Any suggestions?

-- Dean

hplj.csr:

hplj.crt:

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

Michael Sierchio

unread,

Jul 12, 2003, 1:12:01 PM7/12/03

to

Dean Gibson (System Administrator) wrote:
> We have an HP LJ 4600 with an internal JetDirect interface that provides an embedded web server for administration. The web server has the ability to generate a CSR (hplj.csr in the example below), which one can get signed and import the signed certificate back into the web server.
>
> Since we feel that paying $$$ to a real CA to sign the CSR is a waste of money, we thought we'd just try to sign it ourselves, so I did:
>
> openssl x509 -req -in hplj.csr -CA ultimeth.pem -days 3650 -set_serial 01 -out hplj.crt
>
> where "ultimeth.pem" is a self-signed wildcard key/certificate previously generated by openssl and working fine in Apache, Postfix, and IMAP servers.
>
> I then attempted to import (via cut-and-paste) the "hplj.crt" file back into the HP JetDirect web server, but it doesn't like it ("The certificate entered was invalid. Please try again and be sure to include the entire certificate correctly.").
>
> Now, I suspect that this is because the HP JetDirect web server checks to see if the certificate was signed by other than a root CA.
>
> Any suggestions?

Are you sure it's not expecting a PKCS#7 message?

A DER X.509?

etc.

Dean Gibson (System Administrator)

unread,

Jul 12, 2003, 5:00:23 PM7/12/03

to

The screen where I'm supposed to paste the certificate file says: "Please insert the certificate into the text box provided. The certificate needs to be in PEM/Base64 encoding and less than 3kB in size, or the certificate will be rejected."

-- Dean

Umesh

unread,

Jul 14, 2003, 2:23:16 AM7/14/03

to

Hi,

The certificate on JetDirect can be used for both client and server
authentication. JetDirect expects the installed certificate to contain
extendedKeyUsage extension with the values serverAuth and clientAuth. Add the
following line "extendedKeyUsage = clientAuth, serverAuth" in the section
[usr_cert] in openssl.cnf before signing.

Umesh

"Dean Gibson (System Administrator)" wrote:
>
> We have an HP LJ 4600 with an internal JetDirect interface that provides an embedded web server for administration. The web server has the ability to generate a CSR (hplj.csr in the example below), which one can get signed and import the signed certificate back into the web server.
>
> Since we feel that paying $$$ to a real CA to sign the CSR is a waste of money, we thought we'd just try to sign it ourselves, so I did:
>
> openssl x509 -req -in hplj.csr -CA ultimeth.pem -days 3650 -set_serial 01 -out hplj.crt
>
> where "ultimeth.pem" is a self-signed wildcard key/certificate previously generated by openssl and working fine in Apache, Postfix, and IMAP servers.
>
> I then attempted to import (via cut-and-paste) the "hplj.crt" file back into the HP JetDirect web server, but it doesn't like it ("The certificate entered was invalid. Please try again and be sure to include the entire certificate correctly.").
>
> Now, I suspect that this is because the HP JetDirect web server checks to see if the certificate was signed by other than a root CA.
>
> Any suggestions?
>

Dean Gibson (System Administrator)

unread,

Jul 14, 2003, 4:20:20 AM7/14/03

to

I put that in my openssl.cnf in the [ usr_cert ] section, and did:

openssl x509 -req -in hplj4600dn1.csr -CA ultimeth.pem -days 3650 -set_serial 01 -out hplj4600dn1.crt

It didn't help; here's what "openssl x509 -in hplj4600dn1.crt -text -purpose" shows:

Certificate:
Data:
Version: 1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, ST=Washington, L=Mill Creek, O=UltiMeth Systems, OU=Network Security, CN=*.ultimeth.net/emailAddress=secu...@ultimeth.net
Validity
Not Before: Jul 14 08:05:58 2003 GMT
Not After : Jul 11 08:05:58 2013 GMT
Subject: CN=HpLj4600dn1.internal.ultimeth.net, L=Mill Creek, ST=Washington, C=US, O=UltiMeth Systems, OU=0030C1CD3401, OU=J6057A, OU=Network Security
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (700 bit)
Modulus (700 bit):
09:e3:11:2c:bc:01:6f:95:f8:67:bd:be:4f:1f:67:
e8:f5:af:dc:1d:87:91:a4:21:f3:c9:e8:58:47:17:
a0:ad:45:cd:c8:e1:ef:b1:a9:8a:05:7d:6f:f8:75:
ee:97:27:3f:a8:cf:34:55:09:28:fe:a7:8e:77:03:
c9:e5:3b:e2:f2:cb:6b:77:ea:9e:7f:ae:44:8f:c8:
62:5c:aa:3f:fe:84:8c:eb:f3:50:df:6a:d5
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
b8:f0:ae:79:f8:77:1e:e0:dd:7e:40:61:91:04:bd:f2:13:e7:
5f:41:b9:45:b0:e2:68:e5:9d:bc:b4:60:dc:16:98:9d:3e:71:
cf:66:bc:52:04:d2:99:51:fb:bb:cd:6f:76:8b:40:02:e2:8f:
58:0c:cc:97:a9:b5:ac:88:b3:2b:ba:23:6a:07:32:f6:59:d5:
c6:8b:44:9f:b9:9b:4a:b2:88:bb:e4:b6:43:91:26:50:1f:c8:
55:c7:fb:7b:58:de:81:39:a7:08:bd:8d:bc:b8:85:a9:67:2e:
30:70:df:ec:14:58:3e:bd:d6:76:57:a2:36:1f:10:fc:8c:37:
2c:9d
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No

Do I have to add another parameter to openssl x509 ? My openssl.cnf was as it comes from RedHat, with the exception that I changed the default values for responses for generating a self-signed certificate.

-- Dean

Charles B Cranston

unread,

Jul 14, 2003, 11:13:25 AM7/14/03

to

I'm not sure that this is AT ALL relevant but I noticed that the
issuer CN has a wildcard and I wonder 1) what this means, and
2) if this could be confusing something?

Dean Gibson (System Administrator) wrote:

> openssl x509 -req -in hplj4600dn1.csr -CA ultimeth.pem -days 3650 -set_serial 01 -out hplj4600dn1.crt

> It didn't help; here's what "openssl x509 -in hplj4600dn1.crt -text -purpose" shows:

> Certificate:
> Data:
> Version: 1 (0x0)
> Serial Number: 1 (0x1)
> Signature Algorithm: md5WithRSAEncryption
> Issuer: C=US, ST=Washington, L=Mill Creek, O=UltiMeth Systems,
> OU=Network Security, CN=*.ultimeth.net/

......................................^

> emailAddress=secu...@ultimeth.net
> Validity
> Not Before: Jul 14 08:05:58 2003 GMT
> Not After : Jul 11 08:05:58 2013 GMT
> Subject: CN=HpLj4600dn1.internal.ultimeth.net, L=Mill Creek,
> ST=Washington, C=US, O=UltiMeth Systems,
> OU=0030C1CD3401, OU=J6057A, OU=Network Security
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> RSA Public Key: (700 bit)
> Modulus (700 bit):
> 09:e3:11:2c:bc:01:6f:95:f8:67:bd:be:4f:1f:67:

...

--
Charles B (Ben) Cranston
mailto: zb...@umd.edu
http://www.wam.umd.edu/~zben

Dean Gibson (System Administrator)

unread,

Jul 14, 2003, 1:00:23 PM7/14/03

to

I used to generate a self-signed certificate for each hostname I was using for an SSL connection (www.ultimeth.net, imaps.ultimeth.net, smtp.ultimeth.net, etc. ...). Then a couple weeks ago in browsing the Internet, I happened across this site: http://www.freessl.com. I noticed that they sell a "wildcard" SSL certificate. So I thought, if they can sell one, why can't I generate a self-signed one?

The answer is, I/you can! Now I have just one self-signed certificate, and it works with all of my Unix-based SSL-enabled servers.

It seems to me that it is in the best interest of the major CAs to not offer wildcard certificates; that way, they can charge their outrageous prices for each certificate that you need, and when you happen to change a hostname, they are right there at the trough looking for more money.

The JetDirect situation is a bit different, in that the JetDirect firmware generates the private key but never displays it. This means someone has to sign it. I think my problem with the JetDirect server is as Umesh (from HP) stated, that I need to get the generated certificate to include the requested extensions (see CSR below) to the issued certificate.

-- Dean

Certificate Request:
Data:
Version: 2 (0x2)

Subject: CN=HpLj4600dn1.internal.ultimeth.net, L=Mill Creek, ST=Washington, C=US, O=UltiMeth Systems, OU=0030C1CD3401, OU=J6057A, OU=Network Security
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (700 bit)
Modulus (700 bit):
09:e3:11:2c:bc:01:6f:95:f8:67:bd:be:4f:1f:67:

e8:f5:af:dc:1d:87:91:a4:21:f3:c9:e8:58:47:17:
a0:ad:45:cd:c8:e1:ef:b1:a9:8a:05:7d:6f:f8:75:
ee:97:27:3f:a8:cf:34:55:09:28:fe:a7:8e:77:03:
c9:e5:3b:e2:f2:cb:6b:77:ea:9e:7f:ae:44:8f:c8:
62:5c:aa:3f:fe:84:8c:eb:f3:50:df:6a:d5
Exponent: 65537 (0x10001)

Attributes:
Requested Extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Signature Algorithm: md5WithRSAEncryption
02:06:7b:1d:9b:bf:3d:5f:c2:f2:00:b1:6e:e0:c4:ca:71:fb:
a7:83:5b:05:97:9c:09:3b:f5:46:df:ec:aa:bb:f2:59:57:b6:
7e:85:30:28:02:b3:ed:ce:9c:ae:5e:86:02:0e:50:1c:b2:f9:
c7:20:90:0a:5b:e6:34:33:3d:22:13:80:23:14:40:a7:58:d9:
3f:b5:88:01:6c:e6:02:ec:14:59:50:c9:0a:91:a8:b3

Jason Haar

unread,

Jul 17, 2003, 12:22:25 AM7/17/03

to

On Mon, Jul 14, 2003 at 11:35:01AM -0600, Bob DeBolt wrote:
>
> > It seems to me that it is in the best interest of the major
> > CAs to not offer wildcard certificates; that way, they can
> > charge their outrageous prices for each certificate that you
> > need, and when you happen to change a hostname, they are
> > right there at the trough looking for more money.

True - but there's a less evil reason.

If all your servers use the same cert, and *ONE* gets compromised, then
*ALL* your servers are compromised (from a PKI trust point of view)

IMHO You should always use unique certs.

--
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

David Schwartz

unread,

Jul 17, 2003, 12:31:35 AM7/17/03

to

> On Mon, Jul 14, 2003 at 11:35:01AM -0600, Bob DeBolt wrote:

> > > It seems to me that it is in the best interest of the major
> > > CAs to not offer wildcard certificates; that way, they can
> > > charge their outrageous prices for each certificate that you
> > > need, and when you happen to change a hostname, they are
> > > right there at the trough looking for more money.

> True - but there's a less evil reason.
>
> If all your servers use the same cert, and *ONE* gets compromised, then
> *ALL* your servers are compromised (from a PKI trust point of view)
>
> IMHO You should always use unique certs.

The right thing is for the CA to issue a limited wildcard CA cert.
Basically, it would say that a certain key may sign certificates for all
hosts inside a particular domain. That way you only need one key signed by
an outside authority and it doesn't matter if one of your servers are
compromised. (In fact, you can issue it a new key yourself and revoke the
old one yourself.)

DS