Re: [openssl-users] SSL Cert serial number non-uniqueness impact
It's important to note that NSS-based applications (such as Firefox) will actually categorically refuse to connect to a site with an Issuer/serial collision with another certificate it has seen before. So yes, it can cause some applications to fail their SSL connections. -Kyle H On Tue, Jan 16, 2018 at 1:26 AM, Wouter Verhelst wrote: > On 14/01/2018 12:07, pratyush parimal wrote: >> Hi everyone, >> >> I read from several sources that the serial number of a cert MUST be >> unique within a CA. But could someone explain what would happen if the >> serial number was not unique? > > The certificate itself will continue to work (the signature will be > valid), but requesting status on the certificate (e.g., through OCSP or > by doing a lookup in a CRL) will not work as expected as those use the > serial number as an identifier. > >> Would it cause SSL connections to fail in some manner? > No, but if the peer wants to request information on the used certificate > from the CA to verify whether the certificate is still valid, it may end > up receiving information about the wrong certificate. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL Cert serial number non-uniqueness impact
On 14/01/2018 12:07, pratyush parimal wrote: > Hi everyone, > > I read from several sources that the serial number of a cert MUST be > unique within a CA. But could someone explain what would happen if the > serial number was not unique? The certificate itself will continue to work (the signature will be valid), but requesting status on the certificate (e.g., through OCSP or by doing a lookup in a CRL) will not work as expected as those use the serial number as an identifier. > Would it cause SSL connections to fail in some manner? No, but if the peer wants to request information on the used certificate from the CA to verify whether the certificate is still valid, it may end up receiving information about the wrong certificate. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL Cert serial number non-uniqueness impact
The combination of (issuer,serial#) is the only way to get a unique identifier for a certificate. Lots of software depends on certs being uniquely identifiable. What happens if that assertion is not true? Some things will break. What? Well, it depends on the software, and which certs are “duplicates” and so on. There’s no way to know, really. Just don’t do it. For example, if cert-A has a keypair and cert-B has a keypair, then site-B could send a TLS chain with cert-A and while it would look correct, the connection would fail. This is silly if B is doing it, but it is a DoS attack if a man in the middle does it. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL Cert serial number non-uniqueness impact
On 01/14/2018 12:07 PM, pratyush parimal wrote: > I read from several sources that the serial number of a cert MUST be > unique within a CA. But could someone explain what would happen if the > serial number was not unique? Certificate Revocation Lists (CRLs) identify invalid certificates by means of a) the CA keypair that issued it (the pubkey being represented in the signature) and b) the serial number, *not* pubkey / DN / ..., of the invalid cert. If that's not unique, revoking one of the affected certs will have the effect of revoking them all. Regards, -- Jochen Bern Systemingenieur www.binect.de smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] SSL Cert serial number non-uniqueness impact
Hi everyone, I read from several sources that the serial number of a cert MUST be unique within a CA. But could someone explain what would happen if the serial number was not unique? Would it cause SSL connections to fail in some manner? I think I'm a little unclear about the "purpose" of the serial number in the first place. Is it just something the CA uses to keep track of what/how many certificates it has issued, or does it play a part in the SSL connection itself? Thanks in advance! Pratyush -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Serial Number with OpenSSL
* When I see SSL certificates, their serial number is like this : 0A:8D:9A:4Q:8X:1A:0B:88:18:1Z Serial numbers are displayed as hex values, so my guess is you just typed that “as an example” since Q X Z aren’t valid hex characters. Or perhaps it was an extension (like device serial) that isn’t the “real” serial number. On master, you can specify a random serial number -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Serial Number with OpenSSL
FOURES TOM wrote: > When I see SSL certificates, their serial number is like this : > 0A:8D:9A:4Q:8X:1A:0B:88:18:1Z That's an unusual Serial Number, which even if you made this up, is just an integer. IDevID/802.1AR certificates will have a subjectAltName that is sometimes called Serial Number, so I wonder if that is what you are seeing? > So, how could I set my serial file (with serial.old) for to obtain > User Certificates with this serial using my openssl.cnf file? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Serial Number with OpenSSL
4Q? 8X? 1Z? Those are not octets that can show up in serial numbers. -Kyle H On Fri, Dec 1, 2017 at 2:21 PM, FOURES TOM wrote: > Hello, > > When I see SSL certificates, their serial number is like this : > 0A:8D:9A:4Q:8X:1A:0B:88:18:1Z > > So, how could I set my serial file (with serial.old) for to obtain User > Certificates with this serial using my openssl.cnf file? > > > Thank you for your help! > > Have a nice day. > > Aris > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Serial Number with OpenSSL
Hello, When I see SSL certificates, their serial number is like this : 0A:8D:9A:4Q:8X:1A:0B:88:18:1Z So, how could I set my serial file (with serial.old) for to obtain User Certificates with this serial using my openssl.cnf file? Thank you for your help! Have a nice day. Aris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
On 21/08/2017 16:22, Robert Moskowitz wrote: On 08/21/2017 10:03 AM, Salz, Rich wrote: If the root is going to be trusted, make its serial number be one. ☺ Otherwise use eight bytes of random as the serial number, if you follow CABF guidelines. Kind of where my thinking is going. But once I make it '1', it might as well be 1 byte rand! :) Well 1 - 127 random... But no need to make it 20 octets. Just leave it at 8. And yes, I can see some jump on the 'save' 7 bytes bandwagon. Note that while the random bits in the serial number are technically there to defend against attacks on the issuing CA if that CA uses an old/outdated algorithm, the real issue is retaining compatibility with Browsers that blindly assume that certificates are created according to the contractual requirements applied to public CAs such as DigiCert. One of those is 20 bytes max (after DER encoding, thus 159 bits max). Another is at least 64 fresh random bits in each serial number generated by the CA. Another may or may not be 20 bytes min (before DER encoding, thus 153 bits min). Also why I have to work out BER to compare that sizing to DER. Trying to do that today. BER is never shorter than DER. However for internal processing in memory-restricted devices, it may be possible/easy to save space by using a simplified encoding internally, and then convert to DER on the fly when talking to standard software (such as Web Browsers) externally. This will ultimately be a trade off between code size (to do the conversion) and data size (to store the certificate). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
My proposal.
Keep k bits (k/8 octets) long serial numbers for all your certificates, chose a
block cipher operating on blocks of k bits, and operate this block cipher in
CTR mode, with a proper secret key and secret starting counter. That way, no
collision detection is necessary, you’ll be able to generate 2^(k/2) unique k
bits longs serial numbers (in fact, you can generate 2^k unique serial numbers,
but after 2^(k/2) you lose some security guarantees).
With 3DES, k=64, and with AES, k=128.
Since you need to make a tradeoff between security and size, you can play with
lightweight block ciphers such as Simon, Speck, or find some tweakable
lightweight block cipher, maybe from the ECRYPT portfolio (it’s down at this
moment).
Again, the 64bits coming from a CSPRNG is for public CAs only, and the
uniqueness of a serial number is a dirty hack to be able to use a non
collision-resistant hash function a little longer. If you’re confident the hash
function used for signature is collision resistant (for example a member of the
SHA2 or SHA3 family), and you have a purely private CA, don’t bother will all
this, the only hard requirement is the unicity of the tuple {CA name, serial
number}.
Cordialement,
Erwann Abalea
> Le 21 août 2017 à 15:44, Robert Moskowitz a écrit :
>
>
>
> On 08/21/2017 09:36 AM, Salz, Rich wrote:
>> ➢ Thus how large does this random number have
>>
>> It’s also to protect against predicting serial numbers and being able to
>> leverage that. It’s not just (nor really mainly) the MD5 digest attacks.
>> According to CABForum, you need 8 octets. No reason not to use more if you
>> can.
>
> Sure there is. On constrained systems with constrained communication links.
> Every byte counts. My real thrust on this is for IoT. To get IoT developers
> to build around certs and know their products work with them instead of, well
> we will get to it eventually.
>
> When I work with 802.15.4 communications with a 128 byte MTU, there is
> considerable debate over every byte sent. When you tell an IoT chip maker
> that they have to go from 32KB memory to 100MB, they walk out of the room.
>
> Oh, I want DOTS and I2NSF developers to be working with certs from the get
> go, instead waiting for deployments and getting 'production' certs and THEN
> discovering what works and what does not. But IoT is in many ways more of a
> challenge.
>
> So yes, size matters.
>
>>
>>
>> ➢ page was talking about in conjunction with the -CA option. With 'openssl
>> ca' use of the serial file is mandatory according to the man page.
>> There are no command line options for it.
>>
>> Fixed in master and will be part of the next releases; the –rand_serial flag.
>>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
On 08/21/2017 10:03 AM, Salz, Rich wrote: If the root is going to be trusted, make its serial number be one. ☺ Otherwise use eight bytes of random as the serial number, if you follow CABF guidelines. Kind of where my thinking is going. But once I make it '1', it might as well be 1 byte rand! :) Well 1 - 127 random... But no need to make it 20 octets. Just leave it at 8. And yes, I can see some jump on the 'save' 7 bytes bandwagon. Also why I have to work out BER to compare that sizing to DER. Trying to do that today. Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
If the root is going to be trusted, make its serial number be one. ☺ Otherwise use eight bytes of random as the serial number, if you follow CABF guidelines. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
On 08/21/2017 09:36 AM, Salz, Rich wrote: ➢ Thus how large does this random number have It’s also to protect against predicting serial numbers and being able to leverage that. It’s not just (nor really mainly) the MD5 digest attacks. According to CABForum, you need 8 octets. No reason not to use more if you can. Sure there is. On constrained systems with constrained communication links. Every byte counts. My real thrust on this is for IoT. To get IoT developers to build around certs and know their products work with them instead of, well we will get to it eventually. When I work with 802.15.4 communications with a 128 byte MTU, there is considerable debate over every byte sent. When you tell an IoT chip maker that they have to go from 32KB memory to 100MB, they walk out of the room. Oh, I want DOTS and I2NSF developers to be working with certs from the get go, instead waiting for deployments and getting 'production' certs and THEN discovering what works and what does not. But IoT is in many ways more of a challenge. So yes, size matters. ➢ page was talking about in conjunction with the -CA option. With 'openssl ca' use of the serial file is mandatory according to the man page. There are no command line options for it. Fixed in master and will be part of the next releases; the –rand_serial flag. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
➢ Thus how large does this random number have It’s also to protect against predicting serial numbers and being able to leverage that. It’s not just (nor really mainly) the MD5 digest attacks. According to CABForum, you need 8 octets. No reason not to use more if you can. ➢ page was talking about in conjunction with the -CA option. With 'openssl ca' use of the serial file is mandatory according to the man page. There are no command line options for it. Fixed in master and will be part of the next releases; the –rand_serial flag. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
On 08/21/2017 09:20 AM, Salz, Rich via openssl-users wrote: But in doing this, I can't figure out if there is a risk on serial number size for a root CA cert as there is for any other cert. I don’t understand what attack you are concerned about, but the size of the serial number should not matter for *any* certificate. This whole subject is tied into the substitution attack found with using an MD5 hash where you could change some things in the cert and still have a valid cert. The solution, besides dropping MD5, was to include a crypto random number in the beginning of the cert, and the serial was chosen for this sacrifice. Thus how large does this random number have to be to defend against this attack? is 8 octets enough or is 20 needed? This is to make another valid cert with a different keypair. OK, I get this for a cert signed by an issuer. But the root issuer? I don't see the attack. Thus no need to push the root cert's serial to 20 octets. I know I am a little cavalier in describing the attack, but that was the basic point of why to move away from sequential serials to random and what size (though there are other things about CAs that can be discovered by analyzing the sequential serial numbers they used). Meanwhile, I was wrong that -set_serial works with 'openssl ca'. The man page was talking about in conjunction with the -CA option. With 'openssl ca' use of the serial file is mandatory according to the man page. There are no command line options for it. Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using set_serial to control serial number size directly
But in doing this, I can't figure out if there is a risk on serial number size for a root CA cert as there is for any other cert. I don’t understand what attack you are concerned about, but the size of the serial number should not matter for *any* certificate. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Using set_serial to control serial number size directly
I have worked out that: openssl req -config openssl-root.cnf -set_serial 0x$(openssl rand -hex 19) -key private/ca.key.pem\ -subj "$DN"\ -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem allows you to override the serial number select process and thus control what size serial number you use. This also works for openssl ca for signing a csr, so you don't have to deal with the serial file. You can further parameterize this with: -set_serial 0x$(openssl rand -hex $sn) when sn=some number 8 to 19. But in doing this, I can't figure out if there is a risk on serial number size for a root CA cert as there is for any other cert. The nature of the attack, just to me, does not seem to apply to a root CA cert. So that a serial number size of 8 octets is just fine for the root cert. Please correct me if I don't have the risk properly understood. thanks Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Clearing up some of my mistakes on serial number
On 08/20/2017 09:50 AM, Salz, Rich via openssl-users wrote: If you generate 19 bytes or RAND output, it will never exceed 20 bytes encoded. OpenSSL will be generating 159 bits of RAND output, so that it will never exceed 20 bytes encoded. The command-line RAND program is bytes, the C API is bits. So Viktor reminded me about bits, bytes and octets. Too much on the brain. No real excuse. Back to the drawing broad. A bit. 8 bits is a byte. 8 bits is a byte. 8 bits is a byte. 8 bits is a byte. Two hex positions is a byte. One hex position is a nibble. :) I'll get it straight yet. Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Clearing up some of my mistakes on serial number
On 08/20/2017 09:32 AM, Viktor Dukhovni wrote: On Aug 20, 2017, at 8:35 AM, Robert Moskowitz wrote: It is 64 - 160 BITS Correct, with the word "cryptographically random" somewhere in there, for at least 64 of the bits. Which is 8 - 20 OCTETS Correct, since an "octet" is 8 bits. or 4 - 10 BYTES No, a "byte" nowdays is the same as an "octet", though there have been variant definitions of byte, while "octets" have always been 8 bits. ARGH!!! I am going back to bed :) :) Thanks Viktor. But my bit collision analysis still holds true. Collisions are not a concern if openssl rand is a good prf. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Clearing up some of my mistakes on serial number
If you generate 19 bytes or RAND output, it will never exceed 20 bytes encoded. OpenSSL will be generating 159 bits of RAND output, so that it will never exceed 20 bytes encoded. The command-line RAND program is bytes, the C API is bits. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Clearing up some of my mistakes on serial number
> On Aug 20, 2017, at 8:35 AM, Robert Moskowitz wrote: > > It is 64 - 160 BITS Correct, with the word "cryptographically random" somewhere in there, for at least 64 of the bits. > Which is 8 - 20 OCTETS Correct, since an "octet" is 8 bits. > or 4 - 10 BYTES No, a "byte" nowdays is the same as an "octet", though there have been variant definitions of byte, while "octets" have always been 8 bits. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Clearing up some of my mistakes on serial number
It is 64 - 160 BITS
Which is 8 - 20 OCTETS
or 4 - 10 BYTES
And
openssl rand -hex n
Generates n BYTES
Thus what openssl does by default for a self-signed cert, e.g. a root CA
cert of a serial of 8 BYTES is indeed Best Practice, given that if the
first bit were ONE, the serial would then be 8 BYTES.
I had to slow down, take a step away, to see that I was tripping my self
up on the OCTET/BYTE bit.
So I am correcting my guide to use
openssl rand -hex 8
And the probability of a collision is just not worth talking about.
in a population of 2^64, 1 million random selections has a 2.7E-6 %
collision probability.
You go up to 1 billion and the probability does drop to 2.7%.
In a population of 2^159, you have to select 10^18 to get a collision
probability of 6.8E11 %; just not worth dealing with.
So randomly selecting serial numbers will unlikely result in collisions
if you are doing this for you IoT run of 10 million per year, using an 8
BYTE serial number.
And since we are using SHA256 with ECDSA, the known attacks are just not
real. Yet.
So in my highly biased opinion
If you have the memory and bandwidth, go ahead with 8 bytes for serial.
In constrained IoT, 4 bytes works.
Also going to next look at BER over DER for IoT usage.
BTW the above calculations are based on:
p = 1 - e^{-k^2/(2n)}
Where n = total population and k is selected subset.
Bob
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl req -x509 Serial Number
Le 28/04/2013 20:26, redpath a écrit : When an x509 is created using the openssl command it creates a default serial number if one not supplied How is this serial number created (algorithm) in general. A 64bits random number. openssl req -x509 etcetera The default serial number is quite long so just using time_t (long) to set the serial number is not very long (four bytes). So I am interested in what it does. You could also read apps/req.c source code. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl req -x509 Serial Number
When an x509 is created using the openssl command it creates a default serial number if one not supplied How is this serial number created (algorithm) in general. openssl req -x509 etcetera The default serial number is quite long so just using time_t (long) to set the serial number is not very long (four bytes). So I am interested in what it does. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-req-x509-Serial-Number-tp44943.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Extract of Public key and Serial number from Certificate
Thanks Dave.. With fclose() it is working fine :) Thank you very much for your inputs...I shall follow them Dave Thompson-5 wrote: > >> From: owner-openssl-us...@openssl.org On Behalf Of praveenpvs >> Sent: Tuesday, 21 February, 2012 10:24 > >> When I extracted the public key and saved to file, the Public >> key file looks like [---END--- line incomplete] > >> I am not able to figure out what is problem. >> Any suggestions/thoughts?? >> > There's no fclose() in the code you posted. Without that or > at least fflush(), depending on what happens later in the > same process the file MIGHT not get written properly. > > Also, ExtractSerialNumber is storing to gszSerialNumber, > presumably a global buffer, without checking for overflow. > Any buffer overflow in C can be Very Bad News. "serial" > values in X.509 certs nowadays are usually randomized > and 10 or 20 or more bytes (though not by openssl 'ca'). > > And, if fopen() fails it is usually more helpful to show > strerror(errno), or call perror() which does that for you, > rather than just saying "some problem". Similarly, if any > OpenSSL routine (with a few exceptions) returns an error > indication (like NULL from PEM_read_* or <0 from SSL_connect) > it is almost always helpful to show OpenSSL's error queue. > The easy and standard way is to call ERR_print_errors[_fp] > usually on stderr, having done SSL_load_error_strings > (or similar) at initialization. If you want to format > differently see man ERR_get_error . Note > http://www.openssl.org/support/faq.html#PROG6 > http://www.openssl.org/support/faq.html#PROG7 > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > > -- View this message in context: http://old.nabble.com/Extract-of-Public-key-and-Serial-number-from-Certificate-tp33354749p33368555.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Extract of Public key and Serial number from Certificate
> From: owner-openssl-us...@openssl.org On Behalf Of praveenpvs > Sent: Tuesday, 21 February, 2012 10:24 > When I extracted the public key and saved to file, the Public > key file looks like [---END--- line incomplete] > I am not able to figure out what is problem. > Any suggestions/thoughts?? > There's no fclose() in the code you posted. Without that or at least fflush(), depending on what happens later in the same process the file MIGHT not get written properly. Also, ExtractSerialNumber is storing to gszSerialNumber, presumably a global buffer, without checking for overflow. Any buffer overflow in C can be Very Bad News. "serial" values in X.509 certs nowadays are usually randomized and 10 or 20 or more bytes (though not by openssl 'ca'). And, if fopen() fails it is usually more helpful to show strerror(errno), or call perror() which does that for you, rather than just saying "some problem". Similarly, if any OpenSSL routine (with a few exceptions) returns an error indication (like NULL from PEM_read_* or <0 from SSL_connect) it is almost always helpful to show OpenSSL's error queue. The easy and standard way is to call ERR_print_errors[_fp] usually on stderr, having done SSL_load_error_strings (or similar) at initialization. If you want to format differently see man ERR_get_error . Note http://www.openssl.org/support/faq.html#PROG6 http://www.openssl.org/support/faq.html#PROG7 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Extract of Public key and Serial number from Certificate
I am having some problem with the following piece of code..
When I extracted the public key and saved to file, the Public key file looks
like:
-BEGIN PUBLIC KEY-
MIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQCcKeojdze5WBip9ZT5GzNu6gcg
X/Vw4hftCDIQ5TQ6DHDxKxBfapCgKx/4tIgomsm3P9Q6JjhxOZjv/zOvlmQDtVb5
qnNnV8TxnA5n8LT7lrgKX2aiPVLmmaA2VnpAetL7shUUy46Tu+prSIIne3n80vRI
5vR7e5ghrRZAGSs2YQIBAw==
-END PUBLIC KEY
The above Public key is not valid. It misses out -- at the end.
I am not able to figure out what is problem.
Any suggestions/thoughts??
Thank you
Thanks Stephen and DaveThank you very much for your inputs..
X509 *x509;
int main()
{
x509 = NULL;
fp=fopen("RSAKey.cer","rb");
if(fp == NULL)
{
printf("Could not open the file \n");
return 0;
}
else
{
printf("Certificate file opened successfully \n");
}
x509 = PEM_read_X509(fp,NULL,NULL,NULL);
if(x509 == NULL)
{
printf("error reading \n");
}
else
{
printf("reading success\n");
ExtractSerialNumber();
ExtractPubKey();
}
fclose(fp);
X509_free(x509);
}
int ExtractSerialNumber()
{
ASN1_INTEGER *ptr;
int iIndex = 0;
printf("Entered func - ExtractSerialNumber\n");
ptr = X509_get_serialNumber(x509);
printf("\nThe length of the serial number is %d \n",ptr->length);
while(iIndex < (int)ptr->length )
{
sprintf(gszSerialNumber+iIndex*2, "%0.2X",ptr->data[iIndex++]);
}
printf("Serial Number is = %s\n", gszSerialNumber);
return 1;
}
int ExtractPubKey()
{
FILE *fp;
EVP_PKEY *PubKey;
int iRetVal = 0;
printf("Entered func - ExtractPubKey\n");
fp = fopen("RSAPubKey.Dat", "w+");
if(fp == NULL)
{
printf("Some problem with the file opening/creation \n");
return 0;
}
else
{
printf("File is opened \n");
}
PubKey = X509_get_pubkey(x509);
iRetVal = PEM_write_PUBKEY(fp, PubKey);
printf("The return value of PEM_write_PUBKEY is %d \n", iRetVal);
free(fp);
return iRetVal;
}
Thank you very much
--
View this message in context:
http://old.nabble.com/Extract-of-Public-key-and-Serial-number-from-Certificate-tp33354749p33364574.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Extract of Public key and Serial number from Certificate
Thanks Stephen and DaveThank you very much for your inputs..
X509 *x509;
int main()
{
x509 = NULL;
fp=fopen("RSAKey.cer","rb");
if(fp == NULL)
{
printf("Could not open the file \n");
return 0;
}
else
{
printf("Certificate file opened successfully \n");
}
x509 = PEM_read_X509(fp,NULL,NULL,NULL);
if(x509 == NULL)
{
printf("error reading \n");
}
else
{
printf("reading success\n");
ExtractSerialNumber();
ExtractPubKey();
}
fclose(fp);
X509_free(x509);
}
int ExtractSerialNumber()
{
ASN1_INTEGER *ptr;
int iIndex = 0;
printf("Entered func - ExtractSerialNumber\n");
ptr = X509_get_serialNumber(x509);
printf("\nThe length of the serial number is %d \n",ptr->length);
while(iIndex < (int)ptr->length )
{
sprintf(gszSerialNumber+iIndex*2, "%0.2X",ptr->data[iIndex++]);
}
printf("Serial Number is = %s\n", gszSerialNumber);
return 1;
}
int ExtractPubKey()
{
FILE *fp;
EVP_PKEY *PubKey;
int iRetVal = 0;
printf("Entered func - ExtractPubKey\n");
fp = fopen("RSAPubKey.Dat", "w+");
if(fp == NULL)
{
printf("Some problem with the file opening/creation \n");
return 0;
}
else
{
printf("File is opened \n");
}
PubKey = X509_get_pubkey(x509);
iRetVal = PEM_write_PUBKEY(fp, PubKey);
printf("The return value of PEM_write_PUBKEY is %d \n", iRetVal);
free(fp);
return iRetVal;
}
Thank you very much
Dr. Stephen Henson wrote:
>
> On Mon, Feb 20, 2012, Dave Thompson wrote:
>
>> > From: owner-openssl-us...@openssl.org On Behalf Of praveenpvs
>> > Sent: Sunday, 19 February, 2012 23:15
>>
>> > I am new to OPENSSL. I have a certificate, i need to extract
>> > public key and
>> > serial number from it. I know the command to do that, but i
>> > wanted to use
>> > api in my application.
>>
>> > Could you please help me with the corresponding apis for
>> > these two commands?
>> >
>> OpenSSL's X509_* module is mostly older code and does not
>> have a full opaque API as some more recent modules do.
>>
>> You first get the cert into a variable of type X509
>> which is actually struct x509_st declared in x509.h.
>> Actually your code uses a pointer to such a struct
>> which is allocated and deallocated by OpenSSL calls.
>> For a cert in a PEM-format file, which is what your
>> commandlines used, PEM_read_X509 declared in pem.h
>> reads it in and creates the X509. For other input
>> formats there are other options.
>>
>> Then just use fields from the struct as needed.
>> myx509->cert_info->serialNumber is the serial and
>> myx509->cert_info->key is the subjectPublicKeyInfo.
>> Note these are in internal formats: serialNumber
>> is an ASN1_INTEGER which can be converted with ASN1_*
>> routines to (or from) other numeric or text forms;
>> key is another struct containing an AlgorithmIdentifier
>> (containing an OID and possibly but rarely parameters)
>> and a BIT STRING which in turn contains the encoding of
>> the actual key in a format dependent on the type of key.
>> What you do with these depends on what you want to do.
>>
>> When you're done, x509_free() the pointer.
>>
>
> Although some modules don't have an opaque API direct structure access is
> inadvisable if functions exist which can be used instead.
>
> In ths OPs case they do and the functions X509_get_serialNumber and
> X509_get_pubkey should be used.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
>
--
View this message in context:
http://old.nabble.com/Extract-of-Public-key-and-Serial-number-from-Certificate-tp33354749p33361471.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Extract of Public key and Serial number from Certificate
On Mon, Feb 20, 2012, Dave Thompson wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of praveenpvs > > Sent: Sunday, 19 February, 2012 23:15 > > > I am new to OPENSSL. I have a certificate, i need to extract > > public key and > > serial number from it. I know the command to do that, but i > > wanted to use > > api in my application. > > > Could you please help me with the corresponding apis for > > these two commands? > > > OpenSSL's X509_* module is mostly older code and does not > have a full opaque API as some more recent modules do. > > You first get the cert into a variable of type X509 > which is actually struct x509_st declared in x509.h. > Actually your code uses a pointer to such a struct > which is allocated and deallocated by OpenSSL calls. > For a cert in a PEM-format file, which is what your > commandlines used, PEM_read_X509 declared in pem.h > reads it in and creates the X509. For other input > formats there are other options. > > Then just use fields from the struct as needed. > myx509->cert_info->serialNumber is the serial and > myx509->cert_info->key is the subjectPublicKeyInfo. > Note these are in internal formats: serialNumber > is an ASN1_INTEGER which can be converted with ASN1_* > routines to (or from) other numeric or text forms; > key is another struct containing an AlgorithmIdentifier > (containing an OID and possibly but rarely parameters) > and a BIT STRING which in turn contains the encoding of > the actual key in a format dependent on the type of key. > What you do with these depends on what you want to do. > > When you're done, x509_free() the pointer. > Although some modules don't have an opaque API direct structure access is inadvisable if functions exist which can be used instead. In ths OPs case they do and the functions X509_get_serialNumber and X509_get_pubkey should be used. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Extract of Public key and Serial number from Certificate
> From: owner-openssl-us...@openssl.org On Behalf Of praveenpvs > Sent: Sunday, 19 February, 2012 23:15 > I am new to OPENSSL. I have a certificate, i need to extract > public key and > serial number from it. I know the command to do that, but i > wanted to use > api in my application. > Could you please help me with the corresponding apis for > these two commands? > OpenSSL's X509_* module is mostly older code and does not have a full opaque API as some more recent modules do. You first get the cert into a variable of type X509 which is actually struct x509_st declared in x509.h. Actually your code uses a pointer to such a struct which is allocated and deallocated by OpenSSL calls. For a cert in a PEM-format file, which is what your commandlines used, PEM_read_X509 declared in pem.h reads it in and creates the X509. For other input formats there are other options. Then just use fields from the struct as needed. myx509->cert_info->serialNumber is the serial and myx509->cert_info->key is the subjectPublicKeyInfo. Note these are in internal formats: serialNumber is an ASN1_INTEGER which can be converted with ASN1_* routines to (or from) other numeric or text forms; key is another struct containing an AlgorithmIdentifier (containing an OID and possibly but rarely parameters) and a BIT STRING which in turn contains the encoding of the actual key in a format dependent on the type of key. What you do with these depends on what you want to do. When you're done, x509_free() the pointer. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Extract of Public key and Serial number from Certificate
Hi, I am new to OPENSSL. I have a certificate, i need to extract public key and serial number from it. I know the command to do that, but i wanted to use api in my application. Command to get the public key from the certificate: openssl x509 -inform pem -in -pubkey -noout > Command to get the serial number from the certificate: openssl x509 -in -serial -noout > Could you please help me with the corresponding apis for these two commands? Thank you very much. regards Praveen -- View this message in context: http://old.nabble.com/Extract-of-Public-key-and-Serial-number-from-Certificate-tp33354749p33354749.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Displaying Serial Number of Cert via s_client ?
On 01/07/2012 02:01 AM, Ken Adler wrote: I use echo GET | openssl s_client -connect www.google.com:443 -state to troubleshoot https handshakes. Is there a way to get it to return the Serial number (or thumbprint) of the server certificate? openssl s_client -connect www.google.com:443 2>&1|openssl x509 -noout -serial serial=4F9D96D966B0992B54C2957CB4157D4D __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Displaying Serial Number of Cert via s_client ?
I use echo GET | openssl s_client -connect www.google.com:443 -state to troubleshoot https handshakes. Is there a way to get it to return the Serial number (or thumbprint) of the server certificate? Currently, I have to cut and past the returned Base64-encoded certificate into another file and open it in a second step to see the serial number of the certificate the Server is using. Would be totally sweet if I did not have to do this second step. It should just show it like the highlighted section below. Anyone know a secret -option to make the Serial Number display ? ---example below - kadler1-gnmb:~ kadler$ echo GET | openssl s_client -connect www.google.com:443 -state CONNECTED(0003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA verify error:num=20:unable to get local issuer certificate verify return:0 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority --- Server certificate -BEGIN CERTIFICATE- MIIDITCCAoqgAwIBAgIQT52W2WawmStUwpV8tBV9TTANBgkqhkiG9w0BAQUFADBM MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0xMTEwMjYwMDAwMDBaFw0x MzA5MzAyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA3rcmQ6aZhc04pxUJuc8PycNVjIjujI0oJyRLKl6g2Bb6YRhLz21ggNM1QDJy wI8S2OVOj7my9tkVXlqGMaO6hqpryNlxjMzNJxMenUJdOPanrO/6YvMYgdQkRn8B d3zGKokUmbuYOR2oGfs5AER9G5RqeC1prcB6LPrQ2iASmNMCAwEAAaOB5zCB5DAM BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0 ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF AAOBgQAhrNWuyjSJWsKrUtKyNGadeqvu5nzVfsJcKLt0AMkQH0IT/GmKHiSgAgDp ulvKGQSy068Bsn5fFNum21K5mvMSf3yinDtvmX3qUA12IxL/92ZzKbeVCq3Yi7Le IOkKcGQRCMha8X2e7GmlpdWC1ycenlbN0nbVeSv3JUMcafC4+Q== -END CERTIFICATE- subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA Serial Number = 4f 9d 96 d9 66 b0 99 2b 54 c2 95 7c b4 15 7d 4d < Can OpenSSL automatically display this? I manually pasted it here. --- No client certificate CA names sent --- SSL handshake has read 1772 bytes and written 316 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-SHA Session-ID: E5BE28A6B28BB4C098C5F1BCEBB653D062156EC60A7EC309A7147E49914E3FF0 Session-ID-ctx: Master-Key: D0FE87C6090F25B33E54DA906DA6DBF4E52BF1BFEF1FB89D0B5F8DC02B7D12B294DCE463236DB878B60007E789A61EBA Key-Arg : None Start Time: 1325897640 Timeout : 300 (sec) Verify return code: 0 (ok) --- DONE SSL3 alert write:warning:close notify kadler1-gnmb:~ kadler$ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: faled to read serial number(ASN1_INTEGER) from x509 certiticate using openssl
On Wed, Dec 21, 2011, chetanrun wrote: > > How to read certificate details ( serial number, issuer , subject details) > from x509 certificate using Openssl. > > I parsed P12 file using PKCS12_parse(), then retrieved serial number in > ASN1_INTEGER format from objtained x509 certificate. But how do I parse it > so that it can be read. > There are several ways to handle this. One is to convert it to a BIGNUM using ASN1_INTEGER_to_BN(). Alternatively you can use ASN1_STRING_data, ASN1_STRING_length and ASN1_STRING_type. This will return an internal buffer pointer containing the value in big endian format. If the type returned is V_ASN1_NEG_INTEGER the result is negative. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
faled to read serial number(ASN1_INTEGER) from x509 certiticate using openssl
How to read certificate details ( serial number, issuer , subject details) from x509 certificate using Openssl. I parsed P12 file using PKCS12_parse(), then retrieved serial number in ASN1_INTEGER format from objtained x509 certificate. But how do I parse it so that it can be read. -- View this message in context: http://old.nabble.com/faled-to-read-serial-number%28ASN1_INTEGER%29-from-x509-certiticate-using-openssl-tp33017740p33017740.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
verify and the authority and issuer serial number mismatch error
I have a chain that fails to verify: brs% openssl verify -verbose -issuer_checks -CAfile serversTA.pem -untrusted 'servers->users.pem' dua.pem dua.pem: CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 31 at 0 depth lookup:authority and issuer serial number mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 20 at 0 depth lookup:unable to get local issuer certificate I think that's because dua.pem contains an AKID that does not match 'servers->users.pem' (it contains keyID, issuer and serial number). That's true but it's deliberate: servers->users.pem is a cross certificate (issued by serversTA.pem). The key matches (servers->users.pem has a public key that's the same as the public key of the actual issuer of dua.pem). Isn't OpenSSL just wrong in doing this? X.509 (2008) says Certification authorities shall assign certificate serial numbers such that every (issuer, certificate serial number) pair uniquely identifies a single certificate. The keyIdentifier form can be used to select CA certificates during path construction. The authorityCertIssuer, authoritySerialNumber pair can only be used to provide preference to one certificate over others during path construction. Isn't OpenSSL's use of authoritySerialNumber to reject the certificate technically incorrect (according to X.509, though I don't see anything in RFC 5280 permitting it either)? Presumably it's ordinarily harmless: OpenSSL's default config doesn't set authorityCertIssuer, authoritySerialNumber in AKID, and ordinarily everything would match up fine anyway. So to find a problem you'd need a setup with this not recommended AKID and cross certificates. So, lucky me! Presumably there's no test of this in PKITS? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
verify and the authority and issuer serial number mismatch error
I have a chain that fails to verify: brs% openssl verify -verbose -issuer_checks -CAfile serversTA.pem -untrusted 'servers->users.pem' dua.pem dua.pem: CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 31 at 0 depth lookup:authority and issuer serial number mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 20 at 0 depth lookup:unable to get local issuer certificate I think that's because dua.pem contains an AKID that does not match 'servers->users.pem' (it contains keyID, issuer and serial number). That's true but it's deliberate: servers->users.pem is a cross certificate (issued by serversTA.pem). The key matches (servers->users.pem has a public key that's the same as the public key of the actual issuer of dua.pem). Isn't OpenSSL just wrong in doing this? X.509 (2008) says Certification authorities shall assign certificate serial numbers such that every (issuer, certificate serial number) pair uniquely identifies a single certificate. The keyIdentifier form can be used to select CA certificates during path construction. The authorityCertIssuer, authoritySerialNumber pair can only be used to provide preference to one certificate over others during path construction. Isn't OpenSSL's use of authoritySerialNumber to reject the certificate technically incorrect (according to X.509, though I don't see anything in RFC 5280 permitting it either)? Presumably it's ordinarily harmless: OpenSSL's default config doesn't set authorityCertIssuer, authoritySerialNumber in AKID, and ordinarily everything would match up fine anyway. So to find a problem you'd need a setup with this not recommended AKID and cross certificates. So, lucky me! Presumably there's no test of this in PKITS? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to retrieve serial number
Yes, it does take a while to dig through the docs to find things... ASN1_INTEGER * val = X509_get_serialNumber(x); int len = ASN1_STRING_length(val); unsigned char * p = ASN1_STRING_data(val); Then, you can go through the character string to build up as you want. - Original Message - > Hello, > I 'd like to retrieve serial number from X509 certificate, then store > this sn in a memory pointed by char* sn ( in PEM or DER format). I did > not find any function... > Is there any combination of some functions to obtain it ? > Thanks for your help. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How to retrieve serial number
Hello, I 'd like to retrieve serial number from X509 certificate, then store this sn in a memory pointed by char* sn ( in PEM or DER format). I did not find any function... Is there any combination of some functions to obtain it ? Thanks for your help.
RE: How to get the Serial Number
> From: owner-openssl-us...@openssl.org On Behalf Of bhaarat pachori
> Sent: Saturday, 13 November, 2010 08:23
> Actually I am trying to get the Serial number of the der encoded
certificate
>
> AOL_Member_CA.der. For the better understanding I am attaching my
code
Your code appears to process whatever file is specified as argv[1].
I'll assume that is AOL_Member_CA.der but it doesn't really matter.
> struct x509cert_info {
> unsigned char subject[256];
> int subject_len;
> unsigned char issuer[256];
> int issuer_len;
> unsigned char serialnum[128];
> int serialnum_len;
>};
It isn't really safe to assume that DNs (issuer and subject names)
are <= 256 bytes (encoded); see below. There are perfectly valid
naming schemes which produce longer names. Although if you only
handle certs under some particular CA hierarchy, such as AOL,
that might impose limits, I don't know.
I don't believe the standards actually limit serialnum either,
but in practice I believe there is no reason anyone should ever
use more than about 32 bytes, so 128 should be pretty safe.
>static int parse_certificate(struct x509cert_info *cert,
> unsigned char *data, int len)
>{
> X509 *x;
> unsigned char *p;
> const unsigned char *pp;
> int n;
>
> pp = data;
> x = d2i_X509(NULL, &pp, len);
> if (!x) {
> g_printerr ("OpenSSL error during X509 certificate
parsing");
> return -1;
> }
For an error return from libcrypto, you should look at OpenSSL's
error queue. http://www.openssl.org/support/faq.html#PROG6
If you need to do your I/O through glib, as you seem to be doing,
you may need something more like:
u_long err;
while( (err = ERR_get_error()) != 0 ){
ERR_error_string (err, buffer);
/* output and/or log string in buffer */
}
> p = cert->subject;
> n = i2d_X509_NAME(x->cert_info->subject, &p);
> if (n < 0)
> {
> g_printerr("OpenSSL error while encoding subject name");
> return -1;
> }
Ditto in principle, but I don't think i2d(mem) can actually fail
for valid data, which any d2i_X509 return should be.
> printf("\nThe Certificate Subject name is %s\n",p);
The result of DER-encoding is not a C string, and it is
both wrong and unsafe to printf with %s, or strcpy etc.
(Some DN components might not even be characters.)
> if (n > (int)sizeof (cert->subject))
> {
> g_printerr("subject name too long");
> return -1;
> }
In general this is too late, i2d_ has already clobbered memory.
For your case, cert->subject is in a struct followed by field(s)
that don't matter at this point, and so is cert->issuer next.
(i and sn are file-static variables)
> p = cert->serialnum;
> n = i2d_ASN1_INTEGER(x->cert_info->serialNumber, &p);
> if(i==0)
> {
> g_print("\nThe certificate serial number is copied in
serialnumber\n");
> if(g_strlcpy((gchar *)sn, (const gchar
*)x->cert_info->serialNumber, sizeof(sn)))
> {
> i++;
> printf("\nSerial number copied successfully
%s\n",sn);
> }
> }
The serialNumber field in X509->X509_CINF is an ASN1_OBJECT;
it doesn't contain actual data, only pointer, length, and flags.
Saving it at all without properly managing the memory it points
to is unsafe and useless, and assuming those glib(?) routines
do what their names look like, trying to copy it and later compare
it as a C string won't work right, because it's not a C string.
(And the actual pointed-to value isn't a C string either.)
If you want the actual value you need to extract it, but since
you've just (trivially) encoded it into cert->serialnum, and
you normally can't do anything useful with a serial as a number,
why not just use the encoding?
Finally it's not clear what your search is looking for. If you
are looking under a given issuer ONLY, then serial should be
unique (assuming no one can fake the issuer name, or you use
AKID/SKID which are collision-resistant hashes). But in general
across multiple issuers you cannot assume serials are unique.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
How to get the Serial Number
Hi All
I have some query regarding the serial number of the certificate.
Actually I am trying to get the Serial number of the der encoded certificate
AOL_Member_CA.der. For the better understanding I am attaching my code
I would be very very thankful if anyone could help me out.
Regards
Bhaarat.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
struct x509cert_info {
unsigned char subject[256];
int subject_len;
unsigned char issuer[256];
int issuer_len;
unsigned char serialnum[128];
int serialnum_len;
};
//static int find_cert(x509cert_info *, guchar *, gsize *, unsigned char *);
#define PKCS_MODULE "/usr/local/lib/gnome-keyring/gnome-keyring-pkcs11.so"
unsigned char sn[128];
static int i;
gchar *wrt_file = NULL;
gboolean do_list_objects = FALSE;
gboolean do_obj_search = FALSE;
gchar *object_type = NULL;
GckModule *module;
GError *pError = NULL;
struct x509cert_info cert;
guchar*
test_data_read (const gchar *basename, gsize *n_result)
{
GError *error = NULL;
gchar *result;
gchar *file;
file = g_strdup(basename);
if (!g_file_get_contents (file, &result, n_result, &error)) {
printf ("could not read test data file: %s: %s", file, error->message);
g_assert_not_reached ();
}
else
{
printf("\nRead the file successfully\n");
}
g_free (file);
return (guchar*)result;
}
static int parse_certificate(struct x509cert_info *cert,
unsigned char *data, int len)
{
X509 *x;
unsigned char *p;
const unsigned char *pp;
int n;
pp = data;
x = d2i_X509(NULL, &pp, len);
if (!x) {
g_printerr ("OpenSSL error during X509 certificate parsing");
return -1;
}
p = cert->subject;
n = i2d_X509_NAME(x->cert_info->subject, &p);
if (n < 0)
{
g_printerr("OpenSSL error while encoding subject name");
return -1;
}
printf("\nThe Certificate Subject name is %s\n",p);
if (n > (int)sizeof (cert->subject))
{
g_printerr("subject name too long");
return -1;
}
cert->subject_len = n;
p = cert->issuer;
n = i2d_X509_NAME(x->cert_info->issuer, &p);
if (n < 0)
{
g_printerr("OpenSSL error while encoding issuer name");
return -1;
}
if (n > (int)sizeof (cert->issuer))
{
g_printerr("issuer name too long");
return -1;
}
cert->issuer_len = n;
p = cert->serialnum;
n = i2d_ASN1_INTEGER(x->cert_info->serialNumber, &p);
if(i==0)
{
g_print("\nThe certificate serial number is copied in serialnumber\n");
if(g_strlcpy((gchar *)sn, (const gchar *)x->cert_info->serialNumber, sizeof(sn)))
{
i++;
printf("\nSerial number copied successfully %s\n",sn);
}
}
if (n < 0)
{
g_printerr("OpenSSL error while encoding serial number");
return -1;
}
if (n > (int)sizeof (cert->serialnum))
{
g_printerr("serial number too long");
return -1;
}
cert->serialnum_len = n;
return 0;
}
static int find_cert(struct x509cert_info *cert,
unsigned char *data, int len,
unsigned char *sn)
{
X509 *x;
unsigned char *p;
const unsigned char *pp;
int n;
pp = data;
x = d2i_X509(NULL, &pp, len);
if (!x) {
g_printerr ("OpenSSL error during X509 certificate parsing");
return -1;
}
p = cert->subject;
n = i2d_X509_NAME(x->cert_info->subject, &p);
if (n < 0)
{
g_printerr("OpenSSL error while encoding subject name");
return -1;
}
printf("\nThe Certificate Subject name is %s\n",(unsigned char *)x->cert_info->subject);
if (n > (int)sizeof (cert->subject))
{
g_printerr("subject name too long");
return -1;
}
cert->subject_len = n;
p = cert->issuer;
n = i2d_X509_NAME(x->cert_info->issuer, &p);
if (n < 0)
{
g_printerr("OpenSSL error while encoding issuer name");
return -1;
}
if (n > (int)sizeof (cert->issuer))
{
g_printerr("issuer name too long");
return -1;
}
cert->issuer_len = n;
p = cert->serialnum;
n = i2d_ASN1_INTEGER(x->cert_info->serialNumber, &p);
if(!(g_strcmp0((const char *)sn,(const char *)x->cert_info->serialNumber)))
{
g_print("\nThe certificate with serial number found\n");
return 1;
}
if (n < 0)
{
g_printerr("OpenSSL error while encoding serial number");
return -1;
}
if (n > (int)sizeof (cert->serialnum))
{
g_printerr("serial number too long");
return -1;
}
cert->serialnum_len = n;
return 0;
}
int main (int argc, char *argv[])
{
DIR *dip;
struct dirent *dit;
g_type_init ();
module = gck_module_initialize (PKCS_MODULE, NULL, 0, &pError);
gsize cert_len;
guchar *cert_data = test_data_read (argv[1], &cer
RE: Duplicate serial number
> From: owner-openssl-us...@openssl.org On Behalf Of Pascal Delaunay > Sent: Thursday, 23 September, 2010 12:00 > The "database" file (an option in your openssl.conf) handles that perfectly. If you use 'ca'; or as Patrick Patterson said, the scripts which do so. Not 'x509 -req [-CAserial file]'; that stores only the (last-used) number. > 2010/9/22 Andy GOKTAS > So using the "-CAserial serial.srl" might be a good idea to avoid this. > Now this leads me to the next question: > - Besides manually documenting a cross-reference for each certificate > that I sign to a serial number, is there any way to have this scripted > and for an appending log to the serial.srl file that's updated each time > it's used? In short, a list of cert name (=CN perhaps) and serial number > associated with it. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Duplicate serial number
Hi, The "database" file (an option in your openssl.conf) handles that perfectly. Cheers Pascal 2010/9/22 Andy GOKTAS > So using the "-CAserial serial.srl" might be a good idea to avoid this. > > Now this leads me to the next question: > - Besides manually documenting a cross-reference for each certificate that > I sign to a serial number, is there any way to have this scripted and for an > appending log to the serial.srl file that's updated each time it's used? In > short, a list of cert name (=CN perhaps) and serial number associated with > it. > > ?? > > Thanks, > Andy Goktas > > >>> 9/19/2010 1:53 PM >>> > If you generate multiple certs with the same serial number, Firefox (and > anything built with NSS) will absolutely refuse to have anything to do with > those sites. There's no "click 3 times to get access", it's a simple > refusal to talk with a non-standards-compliant server. (Of course, this > puts the owner of the site in a lurch, because he doesn't run the CA in the > vast majority of circumstances.) > > Other TLS clients and browsers likely will do the same. I haven't checked > though. > > -Kyle H > > On Wed, Sep 15, 2010 at 1:34 PM, Andy GOKTAS > wrote: > > Hello, > > > > Just curious if anyone knows, but what happens if I generate multiple > server certs (using my self generated signing CA using openssl) that have > the same assigned serial number? > > > > Does this create a conflict within the network and if users's end up > accessing both certs, kabm? > > > > Is it merely a method of basic tracking on how many certificates a CA > signs? > > > > Thanks, > > Andy Goktas > > __ > > OpenSSL Project http://www.openssl.org > > User Support Mailing Listopenssl-users@openssl.org > > Automated List Manager majord...@openssl.org > > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: Duplicate serial number
Hi Andy: If you use the OpenSSL CA scripts as shipped and documented both in the OpenSSL document, the book, or numerous places on the web, they already use "index.txt" as a list of all issued certificates. So no extra work is needed. Have fun. Patrick. On 2010-09-22, at 4:52 PM, Andy GOKTAS wrote: > So using the "-CAserial serial.srl" might be a good idea to avoid this. > > Now this leads me to the next question: > - Besides manually documenting a cross-reference for each certificate that I > sign to a serial number, is there any way to have this scripted and for an > appending log to the serial.srl file that's updated each time it's used? In > short, a list of cert name (=CN perhaps) and serial number associated with > it. > > ?? > > Thanks, > Andy Goktas > >>>> 9/19/2010 1:53 PM >>> > If you generate multiple certs with the same serial number, Firefox (and > anything built with NSS) will absolutely refuse to have anything to do with > those sites. There's no "click 3 times to get access", it's a simple refusal > to talk with a non-standards-compliant server. (Of course, this puts the > owner of the site in a lurch, because he doesn't run the CA in the vast > majority of circumstances.) > > Other TLS clients and browsers likely will do the same. I haven't checked > though. > > -Kyle H > > On Wed, Sep 15, 2010 at 1:34 PM, Andy GOKTAS wrote: >> Hello, >> >> Just curious if anyone knows, but what happens if I generate multiple server >> certs (using my self generated signing CA using openssl) that have the same >> assigned serial number? >> >> Does this create a conflict within the network and if users's end up >> accessing both certs, kabm? >> >> Is it merely a method of basic tracking on how many certificates a CA signs? >> >> Thanks, >> Andy Goktas >> __ >> OpenSSL Project http://www.openssl.org >> User Support Mailing Listopenssl-users@openssl.org >> Automated List Manager majord...@openssl.org >> > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Duplicate serial number
So using the "-CAserial serial.srl" might be a good idea to avoid this. Now this leads me to the next question: - Besides manually documenting a cross-reference for each certificate that I sign to a serial number, is there any way to have this scripted and for an appending log to the serial.srl file that's updated each time it's used? In short, a list of cert name (=CN perhaps) and serial number associated with it. ?? Thanks, Andy Goktas >>> 9/19/2010 1:53 PM >>> If you generate multiple certs with the same serial number, Firefox (and anything built with NSS) will absolutely refuse to have anything to do with those sites. There's no "click 3 times to get access", it's a simple refusal to talk with a non-standards-compliant server. (Of course, this puts the owner of the site in a lurch, because he doesn't run the CA in the vast majority of circumstances.) Other TLS clients and browsers likely will do the same. I haven't checked though. -Kyle H On Wed, Sep 15, 2010 at 1:34 PM, Andy GOKTAS wrote: > Hello, > > Just curious if anyone knows, but what happens if I generate multiple server > certs (using my self generated signing CA using openssl) that have the same > assigned serial number? > > Does this create a conflict within the network and if users's end up > accessing both certs, kabm? > > Is it merely a method of basic tracking on how many certificates a CA signs? > > Thanks, > Andy Goktas > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Duplicate serial number
Great! Thanks for that information Patrick. :) Thanks, Andy Goktas >>> Patrick Patterson 9/17/2010 6:11 AM >>> Hi Andy: Well, aside from violating most of the standards around PKI, the main problem you will have is revocation - the way you revoke a certificate is to put it's serial number on a CRL. So if you have multiple certs with the same serial number, if you ever need to revoke one of those certificates, you will end up revoking them all. The reason that the standards are written that way is that the principle is that the tuple of the Issuer Name and Serial Number is able to uniquely identify any given certificate, which is important for any number of very good, trust related reasons. Have fun! Patrick. On 2010-09-15, at 4:34 PM, Andy GOKTAS wrote: > Hello, > > Just curious if anyone knows, but what happens if I generate multiple server > certs (using my self generated signing CA using openssl) that have the same > assigned serial number? > > Does this create a conflict within the network and if users's end up > accessing both certs, kabm? > > Is it merely a method of basic tracking on how many certificates a CA signs? > > Thanks, > Andy Goktas > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Duplicate serial number
The serial number has to be unique for the issuer (CA). You can have multiple certificates with the same SubjectName, but the SerialNumber field has to be unique unless you're using a different issuer. Chris On Sun, Sep 19, 2010 at 10:53 PM, wrote: > If you generate multiple certs with the same serial number, Firefox (and > anything built with NSS) will absolutely refuse to have anything to do with > those sites. There's no "click 3 times to get access", it's a simple > refusal to talk with a non-standards-compliant server. (Of course, this > puts the owner of the site in a lurch, because he doesn't run the CA in the > vast majority of circumstances.) > > Other TLS clients and browsers likely will do the same. I haven't checked > though. > > -Kyle H > > On Wed, Sep 15, 2010 at 1:34 PM, Andy GOKTAS > wrote: >> >> Hello, >> >> Just curious if anyone knows, but what happens if I generate multiple >> server certs (using my self generated signing CA using openssl) that have >> the same assigned serial number? >> >> Does this create a conflict within the network and if users's end up >> accessing both certs, kabm? >> >> Is it merely a method of basic tracking on how many certificates a CA >> signs? >> >> Thanks, >> Andy Goktas >> __ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-us...@openssl.org >> Automated List Manager majord...@openssl.org >> > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Duplicate serial number
If you generate multiple certs with the same serial number, Firefox (and anything built with NSS) will absolutely refuse to have anything to do with those sites. There's no "click 3 times to get access", it's a simple refusal to talk with a non-standards-compliant server. (Of course, this puts the owner of the site in a lurch, because he doesn't run the CA in the vast majority of circumstances.) Other TLS clients and browsers likely will do the same. I haven't checked though. -Kyle H On Wed, Sep 15, 2010 at 1:34 PM, Andy GOKTAS wrote: Hello, Just curious if anyone knows, but what happens if I generate multiple server certs (using my self generated signing CA using openssl) that have the same assigned serial number? Does this create a conflict within the network and if users's end up accessing both certs, kabm? Is it merely a method of basic tracking on how many certificates a CA signs? Thanks, Andy Goktas __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME Cryptographic Signature
Re: Duplicate serial number
Hi Andy: Well, aside from violating most of the standards around PKI, the main problem you will have is revocation - the way you revoke a certificate is to put it's serial number on a CRL. So if you have multiple certs with the same serial number, if you ever need to revoke one of those certificates, you will end up revoking them all. The reason that the standards are written that way is that the principle is that the tuple of the Issuer Name and Serial Number is able to uniquely identify any given certificate, which is important for any number of very good, trust related reasons. Have fun! Patrick. On 2010-09-15, at 4:34 PM, Andy GOKTAS wrote: > Hello, > > Just curious if anyone knows, but what happens if I generate multiple server > certs (using my self generated signing CA using openssl) that have the same > assigned serial number? > > Does this create a conflict within the network and if users's end up > accessing both certs, kabm? > > Is it merely a method of basic tracking on how many certificates a CA signs? > > Thanks, > Andy Goktas > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Duplicate serial number
Hello, Just curious if anyone knows, but what happens if I generate multiple server certs (using my self generated signing CA using openssl) that have the same assigned serial number? Does this create a conflict within the network and if users's end up accessing both certs, kabm? Is it merely a method of basic tracking on how many certificates a CA signs? Thanks, Andy Goktas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Getting CRL serial number
Hi everyone,
I created a version 2 CRL, which has the CRL Serial extension set and
now I have to extract the serial number from the CRL to compare it.
I already got as far as extracting the CRL extension by NID. But now
extracting the actual value from the extension is unclear to me. The
headers doesn't help very much.
Also, the OpenSSL book doesn't cover V3 extensions pretty well.
This is my code base so far:
/* CRL serial number is a X509v3 extension */
X509_CRL * crl;
int crl_ext_pos;
X509_EXTENSION * crl_ext;
FILE*fp;
CONF_VALUE *cnf;
ASN1_INTEGER *asn1_serno;
unsigned char *serno;
/* read CRL from file */
if (!(fp = fopen(filename.c_str(), "r"))) {
cerr << "SSL: Error opening CRL file: " << filename << endl;
return ByteVector();
}
/* read into CRL structure */
if ( !( crl = PEM_read_X509_CRL(fp, NULL, NULL, NULL) ) ) {
cerr << "SSL: Error reading CRL into structure: " << filename
<< endl;
return ByteVector();
}
fclose(fp);
/* extract "X509v3 CRL Number" extension */
/* extensions NIDs NID_xxx_yyy are defined in openssl/objects.h */
/* get the position of the extension in the crl as an integer and
pass it to get_ext to finally receive the extension value */
crl_ext_pos = X509_CRL_get_ext_by_NID(crl, NID_crl_number, -1);
crl_ext = X509_CRL_get_ext(crl, crl_ext_pos);
I appreciate your help! Please CC my when answering, because I am not
on the list.
Thank you very much!
Best, René
smime.p7s
Description: S/MIME cryptographic signature
RE: CA generation/certificate serial number
smime.p7m Description: S/MIME encrypted message
Re: CA generation/certificate serial number
openssl is VERY tolerant concerning the encoding/decoding of an INTEGER
value.
Other decoders may not like such things as length 0 etc.
When converting such a beast from DER to PEM or the other way, you might
have a surprise.
From X.690:
8.3 Encoding of an integer value
8.3.1 The encoding of an integer value shall be primitive. The contents
octets shall consist of one or more octets.
8.3.2 If the contents octets of an integer value encoding consist of
more than one octet, then the bits of the first octet and bit 8 of the
second octet:
a) shall not all be ones; and
b) shall not all be zero.
NOTE – These rules ensure that an integer value is always encoded in the
smallest possible number of octets.
8.3.3 The contents octets shall be a two’s complement binary number
equal to the integer value, and consisting of bits 8 to 1 of the first
octet, followed by bits 8 to 1 of the second octet, followed by bits 8
to 1 of each octet in turn up to and including the last octet of the
contents octets.
NOTE – The value of a two’s complement binary number is derived by
numbering the bits in the contents octets, starting with bit 1 of the
last octet as bit zero and ending the numbering with bit 8 of the first
octet. Each bit is assigned a numerical value of 2N, where N is its
position in the above numbering sequence. The value of the two’s
complement binary number is obtained by summing the numerical values
assigned to each bit for those bits which are set to one, excluding bit
8 of the first octet, and then reducing this value by the numerical
value assigned to bit 8 of the first octet if that bit is set to
one.Giang Nguyen wrote:
nils
Frédéric Donnat wrote:
Hi,
Sorry for the mistake (nothing to deal with openssl.cnf file). I was just
looking for ca.txt file.
Is it normal behavior of openssl to be able to view a certificate without
serial number using (without any error mentioned):
openssl x509 -in some_cert_without_sn.pem -text
But to be unable to verify it using:
openssl verify -CAfile some_cert_without_sn.pem some_cert_without_sn.pem
Sample: (attached self-sign cert name pipo-bad.pem)
hmm, the attached certificate as has a serial number it's 0x0
actually the attachment
http://www.mail-archive.com/openssl-users@openssl.org/msg41447/pipo-bad.pem
does not have a serial number; that field is has lenght of zero:
0:d=0 hl=4 l= 546 cons: SEQUENCE
4:d=1 hl=4 l= 395 cons: SEQUENCE
8:d=2 hl=2 l= 3 cons: cont [ 0 ]
10:d=3 hl=2 l= 1 prim: INTEGER :02
13:d=2 hl=2 l= 0 prim: INTEGER :00
15:d=2 hl=2 l= 13 cons: SEQUENCE
17:d=3 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption
similar to the certificate i posted in the "signature failure when certificate
contains no serial number (ie, not one that equals zero)?" thread:
arch [apps]$ cat /tmp/no_serial.pem
-BEGIN CERTIFICATE-
MIIBCzCBtqADAgECAgAwDQYJKoZIhvcNAQEFBQAwDzENMAsGA1UEAxMEdGVzdDAe
Fw0wNDA3MjIxNzU3MTlaFw0xMzAxMjMxNTIxMzVaMA8xDTALBgNVBAMTBHRlc3Qw
XDANBgkqhkiG9w0BAQEFAANLADBIAkEAsUDN7wFJBTJC+/BtbDzomHvDA6xMAxpx
zy4pDdkKBH0Key8yCxJ8dH1c8vNwaRfC5QgMZDxBY+o2n2DvrGrL+QIDAQABMA0G
CSqGSIb3DQEBBQUAA0EAiWk2QM5lxijnjQE/D/tsoWf0LZvPIuPC7laTUFUrAIKr
JbkAQ9rrf33pf+7JIhiJIgFxVVgOv2PXYKPWC7duUA==
-END CERTIFICATE-
0:d=0 hl=4 l= 267 cons: SEQUENCE
4:d=1 hl=3 l= 182 cons: SEQUENCE
7:d=2 hl=2 l= 3 cons: cont [ 0 ]
9:d=3 hl=2 l= 1 prim: INTEGER :02
12:d=2 hl=2 l= 0 prim: INTEGER :00
14:d=2 hl=2 l= 13 cons: SEQUENCE
16:d=3 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption
[EMAIL PROTECTED] simple]$ LD_LIBRARY_PATH=/usr/local/ossl-0.9.8/lib
/usr/local/ossl-0.9.8/bin/openssl verify -verbose -CAfile pipo-bad.pem
pipo-bad.pem
pipo-bad.pem: /C=UK/CN=OpenSSL Group
error 7 at 0 depth lookup:certificate signature failure
18588:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:218:
18588:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:a_verify.c:168:
well the signature really seems to be wrong. How did you create
the certificate ?
as to how i generated the certificate with no serial number, i simply commented out the code and
ran "./openssl req" without specifying "-set_serial":
arch [apps]$ diff -u req.c.BAK req.c
--- req.c.BAK 2007-12-29 12:26:41.0 -0800
+++ req.c 2007-12-29 12:39:11.0 -0800
@@ -937,16 +937,18 @@
{
if (!X509_set_serialNumber(x509ss, serial))
goto end;
}
- else
- {
- if (!rand_serial(NULL,
- X509_get_serialNumber(x509ss)))
- goto end;
-
Re: CA generation/certificate serial number
nils
>Frédéric Donnat wrote:
>
> Hi,
>
> Sorry for the mistake (nothing to deal with openssl.cnf file). I was just
> looking for ca.txt file.
>
> Is it normal behavior of openssl to be able to view a certificate without
> serial number using (without any error mentioned):
> openssl x509 -in some_cert_without_sn.pem -text
> But to be unable to verify it using:
> openssl verify -CAfile some_cert_without_sn.pem some_cert_without_sn.pem
>
>
> Sample: (attached self-sign cert name pipo-bad.pem)
>
>hmm, the attached certificate as has a serial number it's 0x0
actually the attachment
http://www.mail-archive.com/openssl-users@openssl.org/msg41447/pipo-bad.pem
does not have a serial number; that field is has lenght of zero:
0:d=0 hl=4 l= 546 cons: SEQUENCE
4:d=1 hl=4 l= 395 cons: SEQUENCE
8:d=2 hl=2 l= 3 cons: cont [ 0 ]
10:d=3 hl=2 l= 1 prim: INTEGER :02
13:d=2 hl=2 l= 0 prim: INTEGER :00
15:d=2 hl=2 l= 13 cons: SEQUENCE
17:d=3 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption
similar to the certificate i posted in the "signature failure when certificate
contains no serial number (ie, not one that equals zero)?" thread:
arch [apps]$ cat /tmp/no_serial.pem
-BEGIN CERTIFICATE-
MIIBCzCBtqADAgECAgAwDQYJKoZIhvcNAQEFBQAwDzENMAsGA1UEAxMEdGVzdDAe
Fw0wNDA3MjIxNzU3MTlaFw0xMzAxMjMxNTIxMzVaMA8xDTALBgNVBAMTBHRlc3Qw
XDANBgkqhkiG9w0BAQEFAANLADBIAkEAsUDN7wFJBTJC+/BtbDzomHvDA6xMAxpx
zy4pDdkKBH0Key8yCxJ8dH1c8vNwaRfC5QgMZDxBY+o2n2DvrGrL+QIDAQABMA0G
CSqGSIb3DQEBBQUAA0EAiWk2QM5lxijnjQE/D/tsoWf0LZvPIuPC7laTUFUrAIKr
JbkAQ9rrf33pf+7JIhiJIgFxVVgOv2PXYKPWC7duUA==
-END CERTIFICATE-
0:d=0 hl=4 l= 267 cons: SEQUENCE
4:d=1 hl=3 l= 182 cons: SEQUENCE
7:d=2 hl=2 l= 3 cons: cont [ 0 ]
9:d=3 hl=2 l= 1 prim: INTEGER :02
12:d=2 hl=2 l= 0 prim: INTEGER :00
14:d=2 hl=2 l= 13 cons: SEQUENCE
16:d=3 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption
>
>
>[EMAIL PROTECTED] simple]$ LD_LIBRARY_PATH=/usr/local/ossl-0.9.8/lib
>/usr/local/ossl-0.9.8/bin/openssl verify -verbose -CAfile pipo-bad.pem
>pipo-bad.pem
>pipo-bad.pem: /C=UK/CN=OpenSSL Group
>error 7 at 0 depth lookup:certificate signature failure
>18588:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:218:
>18588:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
>lib:a_verify.c:168:
>
>well the signature really seems to be wrong. How did you create
>the certificate ?
as to how i generated the certificate with no serial number, i simply commented
out the code and ran "./openssl req" without specifying "-set_serial":
arch [apps]$ diff -u req.c.BAK req.c
--- req.c.BAK 2007-12-29 12:26:41.0 -0800
+++ req.c 2007-12-29 12:39:11.0 -0800
@@ -937,16 +937,18 @@
{
if (!X509_set_serialNumber(x509ss, serial))
goto end;
}
- else
- {
- if (!rand_serial(NULL,
- X509_get_serialNumber(x509ss)))
- goto end;
- }
if (!X509_set_issuer_name(x509ss,
X509_REQ_get_subject_name(req))) goto end;
again, this is not causing any problems for me, just curious.
thanks.
>
>Cheers,
>Nils
_
The best games are on Xbox 360. Click here for a special offer on an Xbox 360
Console.
http://www.xbox.com/en-US/hardware/wheretobuy/__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: signature failure when certificate contains no serial number (ie, not one that equals zero)?
sorry please ignore; this had been asked before: http://www.mail-archive.com/openssl-users@openssl.org/msg41502.html > From: [EMAIL PROTECTED] > To: openssl-users@openssl.org > Subject: signature failure when certificate contains no serial number (ie, > not one that equals zero)? > Date: Sat, 29 Dec 2007 21:05:02 + > > > i was messing around with (self-signed) certificate creation/signing > and ran into this. the following two certificates are the same except > for the serial number: "with_serial" has a serial number that is zero, > and "no_serial" does not have any serial number. > > the "with_serial" certificate verifies ok, but the "no_serial" one > fails verification with "certificate signature failure." > > is this expected? > > if not, i thought the signing is applied to the entire blob of data, > so with or without the serial number, the signing code wouldn't know > or care to know, so it's probably not a signing problem. then is it a > verification problem then? > > not that this is causing problems for me. just curious. > > thanks. > > arch [apps]$ ./openssl version > OpenSSL 0.9.8g 19 Oct 2007 > arch [apps]$ > arch [apps]$ ./openssl verify -CAfile /tmp/with_serial.pem > /tmp/with_serial.pem > /tmp/with_serial.pem: OK > arch [apps]$ > arch [apps]$ ./openssl verify -CAfile /tmp/no_serial.pem /tmp/no_serial.pem > /tmp/no_serial.pem: /CN=test > error 7 at 0 depth lookup:certificate signature failure > 15143:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:235: > 15143:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP > lib:a_verify.c:168: > arch [apps]$ > arch [apps]$ ./openssl asn1parse -in /tmp/with_serial.pem > 0:d=0 hl=4 l= 268 cons: SEQUENCE > 4:d=1 hl=3 l= 183 cons: SEQUENCE > 7:d=2 hl=2 l= 3 cons: cont [ 0 ] > 9:d=3 hl=2 l= 1 prim: INTEGER :02 > 12:d=2 hl=2 l= 1 prim: INTEGER :00 > 15:d=2 hl=2 l= 13 cons: SEQUENCE > 17:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption > 28:d=3 hl=2 l= 0 prim: NULL > 30:d=2 hl=2 l= 15 cons: SEQUENCE > 32:d=3 hl=2 l= 13 cons: SET > 34:d=4 hl=2 l= 11 cons: SEQUENCE > 36:d=5 hl=2 l= 3 prim: OBJECT :commonName > 41:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test > 47:d=2 hl=2 l= 30 cons: SEQUENCE > 49:d=3 hl=2 l= 13 prim: UTCTIME :040722175719Z > 64:d=3 hl=2 l= 13 prim: UTCTIME :130123152135Z > 79:d=2 hl=2 l= 15 cons: SEQUENCE > 81:d=3 hl=2 l= 13 cons: SET > 83:d=4 hl=2 l= 11 cons: SEQUENCE > 85:d=5 hl=2 l= 3 prim: OBJECT :commonName > 90:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test > 96:d=2 hl=2 l= 92 cons: SEQUENCE > 98:d=3 hl=2 l= 13 cons: SEQUENCE > 100:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption > 111:d=4 hl=2 l= 0 prim: NULL > 113:d=3 hl=2 l= 75 prim: BIT STRING > 190:d=1 hl=2 l= 13 cons: SEQUENCE > 192:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption > 203:d=2 hl=2 l= 0 prim: NULL > 205:d=1 hl=2 l= 65 prim: BIT STRING > arch [apps]$ > arch [apps]$ ./openssl asn1parse -in /tmp/no_serial.pem > 0:d=0 hl=4 l= 267 cons: SEQUENCE > 4:d=1 hl=3 l= 182 cons: SEQUENCE > 7:d=2 hl=2 l= 3 cons: cont [ 0 ] > 9:d=3 hl=2 l= 1 prim: INTEGER :02 > 12:d=2 hl=2 l= 0 prim: INTEGER :00 > 14:d=2 hl=2 l= 13 cons: SEQUENCE > 16:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption > 27:d=3 hl=2 l= 0 prim: NULL > 29:d=2 hl=2 l= 15 cons: SEQUENCE > 31:d=3 hl=2 l= 13 cons: SET > 33:d=4 hl=2 l= 11 cons: SEQUENCE > 35:d=5 hl=2 l= 3 prim: OBJECT :commonName > 40:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test > 46:d=2 hl=2 l= 30 cons: SEQUENCE > 48:d=3 hl=2 l= 13 prim: UTCTIME :040722175719Z > 63:d=3 hl=2 l= 13 prim: UTCTIME :130123152135Z > 78:d=2 hl=2 l= 15 cons: SEQUENCE > 80:d=3 hl=2 l= 13 cons: SET > 82:d=4 hl=2 l= 11 cons: SEQUENCE > 84:d=5 hl=2 l= 3 prim: OBJECT :commonName > 89:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test > 95:d=2 hl=2 l= 92 cons: SEQUENCE > 97:d=3 hl=2 l= 13 cons: SEQUENCE > 99:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption > 110:d=4 hl=2 l= 0 prim: NULL > 112:d=3 hl=2 l= 75 prim: BIT STRING > 189:d=1 hl=2 l= 13 cons: SEQUENCE > 191:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption > 202:d=2 hl=2 l= 0 prim: NULL > 204:d=1 hl=2 l= 65 prim: BIT STRING > arch [apps]$ > arch [apps]$ cat /tmp/with_serial.pem > -BEGIN CERTIFICATE- > MIIBDDCBt6ADAgECAgEAMA0GCSqGSIb3DQEBBQUAMA8xDTALBgNVBAMTBHRlc3Qw > HhcNMDQwNzIyMTc1NzE5WhcNMTMwMTIzMTUyMTM1WjAPMQ0wCwYDVQQDEwR0ZXN0 > MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALFAze8BSQUyQvvwbWw86Jh7wwOsTAMa > cc8uKQ3ZCgR9CnsvMgsSfHR9XPLzcGkXwuUIDGQ8QWPqNp9g76xqy/kCAwEAATAN > BgkqhkiG9w0BAQUFAANBAHtxTN9bC7jCJDs9iKBE7O2U4jMlLievUR3YgWsrfxVJ > k1v/vXdL4H8/+QndErV8Bl8AavnsjQjFgfPiOs3pi70= > -END CERTIFICATE- > arch [apps]$
signature failure when certificate contains no serial number (ie, not one that equals zero)?
i was messing around with (self-signed) certificate creation/signing and ran into this. the following two certificates are the same except for the serial number: "with_serial" has a serial number that is zero, and "no_serial" does not have any serial number. the "with_serial" certificate verifies ok, but the "no_serial" one fails verification with "certificate signature failure." is this expected? if not, i thought the signing is applied to the entire blob of data, so with or without the serial number, the signing code wouldn't know or care to know, so it's probably not a signing problem. then is it a verification problem then? not that this is causing problems for me. just curious. thanks. arch [apps]$ ./openssl version OpenSSL 0.9.8g 19 Oct 2007 arch [apps]$ arch [apps]$ ./openssl verify -CAfile /tmp/with_serial.pem /tmp/with_serial.pem /tmp/with_serial.pem: OK arch [apps]$ arch [apps]$ ./openssl verify -CAfile /tmp/no_serial.pem /tmp/no_serial.pem /tmp/no_serial.pem: /CN=test error 7 at 0 depth lookup:certificate signature failure 15143:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:235: 15143:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:168: arch [apps]$ arch [apps]$ ./openssl asn1parse -in /tmp/with_serial.pem 0:d=0 hl=4 l= 268 cons: SEQUENCE 4:d=1 hl=3 l= 183 cons: SEQUENCE 7:d=2 hl=2 l= 3 cons: cont [ 0 ] 9:d=3 hl=2 l= 1 prim: INTEGER :02 12:d=2 hl=2 l= 1 prim: INTEGER :00 15:d=2 hl=2 l= 13 cons: SEQUENCE 17:d=3 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption 28:d=3 hl=2 l= 0 prim: NULL 30:d=2 hl=2 l= 15 cons: SEQUENCE 32:d=3 hl=2 l= 13 cons: SET 34:d=4 hl=2 l= 11 cons: SEQUENCE 36:d=5 hl=2 l= 3 prim: OBJECT:commonName 41:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 47:d=2 hl=2 l= 30 cons: SEQUENCE 49:d=3 hl=2 l= 13 prim: UTCTIME :040722175719Z 64:d=3 hl=2 l= 13 prim: UTCTIME :130123152135Z 79:d=2 hl=2 l= 15 cons: SEQUENCE 81:d=3 hl=2 l= 13 cons: SET 83:d=4 hl=2 l= 11 cons: SEQUENCE 85:d=5 hl=2 l= 3 prim: OBJECT:commonName 90:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 96:d=2 hl=2 l= 92 cons: SEQUENCE 98:d=3 hl=2 l= 13 cons: SEQUENCE 100:d=4 hl=2 l= 9 prim: OBJECT:rsaEncryption 111:d=4 hl=2 l= 0 prim: NULL 113:d=3 hl=2 l= 75 prim: BIT STRING 190:d=1 hl=2 l= 13 cons: SEQUENCE 192:d=2 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption 203:d=2 hl=2 l= 0 prim: NULL 205:d=1 hl=2 l= 65 prim: BIT STRING arch [apps]$ arch [apps]$ ./openssl asn1parse -in /tmp/no_serial.pem 0:d=0 hl=4 l= 267 cons: SEQUENCE 4:d=1 hl=3 l= 182 cons: SEQUENCE 7:d=2 hl=2 l= 3 cons: cont [ 0 ] 9:d=3 hl=2 l= 1 prim: INTEGER :02 12:d=2 hl=2 l= 0 prim: INTEGER :00 14:d=2 hl=2 l= 13 cons: SEQUENCE 16:d=3 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption 27:d=3 hl=2 l= 0 prim: NULL 29:d=2 hl=2 l= 15 cons: SEQUENCE 31:d=3 hl=2 l= 13 cons: SET 33:d=4 hl=2 l= 11 cons: SEQUENCE 35:d=5 hl=2 l= 3 prim: OBJECT:commonName 40:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 46:d=2 hl=2 l= 30 cons: SEQUENCE 48:d=3 hl=2 l= 13 prim: UTCTIME :040722175719Z 63:d=3 hl=2 l= 13 prim: UTCTIME :130123152135Z 78:d=2 hl=2 l= 15 cons: SEQUENCE 80:d=3 hl=2 l= 13 cons: SET 82:d=4 hl=2 l= 11 cons: SEQUENCE 84:d=5 hl=2 l= 3 prim: OBJECT:commonName 89:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 95:d=2 hl=2 l= 92 cons: SEQUENCE 97:d=3 hl=2 l= 13 cons: SEQUENCE 99:d=4 hl=2 l= 9 prim: OBJECT:rsaEncryption 110:d=4 hl=2 l= 0 prim: NULL 112:d=3 hl=2 l= 75 prim: BIT STRING 189:d=1 hl=2 l= 13 cons: SEQUENCE 191:d=2 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption 202:d=2 hl=2 l= 0 prim: NULL 204:d=1 hl=2 l= 65 prim: BIT STRING arch [apps]$ arch [apps]$ cat /tmp/with_serial.pem -BEGIN CERTIFICATE- MIIBDDCBt6ADAgECAgEAMA0GCSqGSIb3DQEBBQUAMA8xDTALBgNVBAMTBHRlc3Qw HhcNMDQwNzIyMTc1NzE5WhcNMTMwMTIzMTUyMTM1WjAPMQ0wCwYDVQQDEwR0ZXN0 MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALFAze8BSQUyQvvwbWw86Jh7wwOsTAMa cc8uKQ3ZCgR9CnsvMgsSfHR9XPLzcGkXwuUIDGQ8QWPqNp9g76xqy/kCAwEAATAN BgkqhkiG9w0BAQUFAANBAHtxTN9bC7jCJDs9iKBE7O2U4jMlLievUR3YgWsrfxVJ k1v/vXdL4H8/+QndErV8Bl8AavnsjQjFgfPiOs3pi70= -END CERTIFICATE- arch [apps]$ arch [apps]$ cat /tmp/no_serial.pem -BEGIN CERTIFICATE- MIIBCzCBtqADAgECAgAwDQYJKoZIhvcNAQEFBQAwDzENMAsGA1UEAxMEdGVzdDAe Fw0wNDA3MjIxNzU3MTlaFw0xMzAxMjMxNTIxMzVaMA8xDTALBgNVBAMTBHRlc3Qw XDANBgkqhkiG9w0BAQEFAANLADBIAkEAsUDN7wFJBTJC+/BtbDzomHvDA6xMAxpx zy4pDdkKBH0Key8yCxJ8dH1c8vNwaRfC5QgMZDxBY+o2n2DvrGrL+QIDAQABMA0G CSqGSIb3DQEBBQUAA0EAiWk2QM5lxijnjQE/D/tsoWf0LZv
Re: segfault in ASN1_INTEGER_to_BN() to get serial number from a certificate
Jeremie Le Hen wrote:
% char *tls_serial_number(X509 *peer)
% {
% ASN1_INTEGER *sn;
% BIGNUM bn;
% char *bnstr, *snstr;
% size_t len;
%
% if ((sn = X509_get_serialNumber(peer)) == 0)
% return (0);
% ASN1_INTEGER_to_BN(sn, &bn);
This can not work, you can not avoid dynamic allocation of bn.
You are telling openssl to reuse the value inside bn, that will be
random content from the stack.
You might make it work by initialising bn to zero, but you'd depend for
it to work on details of the internal working of ASN1_INTEGER_to_BN
Use either :
BIGNUM *bn;
bn = ASN1_INTEGER_to_BN(sn, NULL);
BN_free(bn);
or
BIGNUM *bn= NULL;
ASN1_INTEGER_to_BN(sn, bn);
BN_free(bn);
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
segfault in ASN1_INTEGER_to_BN() to get serial number from a certificate
Hi list,
Please Cc: me when replying.
I've coded the following function (in Postfix FWIW). Nothing tricky:
% char *tls_serial_number(X509 *peer)
% {
% ASN1_INTEGER *sn;
% BIGNUM bn;
% char *bnstr, *snstr;
% size_t len;
%
% if ((sn = X509_get_serialNumber(peer)) == 0)
% return (0);
% ASN1_INTEGER_to_BN(sn, &bn);
% if ((bnstr = BN_bn2hex(&bn)) == NULL)
% msg_fatal("insufficient memory for bignum stringification: %m");
% snstr = mystrdup(bnstr);
% OPENSSL_free(bnstr);
% return (snstr);
% }
Unfortunately, ASN1_INTEGER_to_BN() happens to trigger a SEGFAULT.
Here is the trace from gdb(1):
% (gdb) bt
% #0 0x281cf1c8 in BN_new () from /lib/libcrypto.so.4
% #1 0x281cf2c5 in bn_expand2 () from /lib/libcrypto.so.4
% #2 0x281cf6cb in BN_bin2bn () from /lib/libcrypto.so.4
% #3 0x281c93c9 in ASN1_INTEGER_to_BN () from /lib/libcrypto.so.4
% #4 0x0805e106 in tls_serial_number (peer=0x80b1700) at tls_verify.c:332
% #5 0x0805cf55 in tls_server_start (props=0xbfbfe280) at tls_server.c:682
% #6 0x080501be in smtpd_start_tls (state=0xbfbfe320) at smtpd.c:3569
% #7 0x0805038b in starttls_cmd (state=0xbfbfe320, argc=1,
% unused_argv=0x809fe48) at smtpd.c:3699
% #8 0x08050a81 in smtpd_proto (state=0xbfbfe320) at smtpd.c:4022
% #9 0x08050ecd in smtpd_service (stream=0x80b2608, service=0xbfbfef2d "smtp",
% argv=0xbfbfe280) at smtpd.c:4149
% #10 0x0805ae2a in single_server_wakeup (fd=134933256) at single_server.c:257
% #11 0x08074c96 in event_loop (delay=-1077942944) at events.c:1080
% #12 0x0805b62c in single_server_main (argc=8, argv=0xbfbfee74,
% service=0x8050de8 ) at single_server.c:722
% #13 0x080515d1 in main (argc=8, argv=0xbfbfee74) at smtpd.c:4585
% (gdb) frame 4
% #4 0x0805e106 in tls_serial_number (peer=0x80b1700) at tls_verify.c:332
% 332 ASN1_INTEGER_to_BN(sn, &bn);
% (gdb) print *peer
% $1 = {cert_info = 0x80af080, sig_alg = 0x80b0590, signature = 0x80b05a0,
% valid = 1, references = 2,
% name = 0x80d4400 "/C=FR/O=TEST/OU=Clients/CN=diogene.jeremie.int",
% ex_data = {sk = 0x0, dummy = 0}, ex_pathlen = -1, ex_flags = 263,
% ex_kusage = 128, ex_xkusage = 2, ex_nscert = 0, skid = 0x80d5030,
% akid = 0x80d5080, sha1_hash = "\016ûd2v;\177QØ61Ä\005I^\0252hMJ", aux = 0x0}
% (gdb) print *peer->cert_info
% $2 = {version = 0x80b05b0, serialNumber = 0x80b04b0, signature = 0x80b04c0,
% issuer = 0x80b04d0, validity = 0x80b0500, subject = 0x80b0530,
% key = 0x80b0560, issuerUID = 0x0, subjectUID = 0x0, extensions = 0x80d2320}
% (gdb) print sn
% $2 = (ASN1_INTEGER *) 0xbfbfe280
% (gdb) print *sn
% $1 = {length = 134834432, type = 134948360,
% data = 0x2 , flags = 300}
What's wrong with my code? The certificate used by the TLS client is
not special in any way:
% Certificate:
% Data:
% Version: 3 (0x2)
% Serial Number:
% d3:f9:b3:9a:02:3a:72:10
% Signature Algorithm: sha1WithRSAEncryption
% Issuer: C=FR, O=TEST, OU=JEREMIE, CN=Autorite de certification racine
Test
% Validity
% Not Before: Jul 25 19:00:13 2007 GMT
% Not After : Jul 24 19:00:13 2008 GMT
% Subject: C=FR, O=TEST, OU=Clients, CN=diogene.jeremie.int
% Subject Public Key Info:
% Public Key Algorithm: rsaEncryption
% RSA Public Key: (2048 bit)
% Modulus (2048 bit):
% ...
% X509v3 extensions:
% X509v3 Subject Key Identifier:
% 2A:E9:A1:01:9A:74:4F:EE:23:10:A9:9C:97:C3:B7:77:55:E0:B4:45
% X509v3 Authority Key Identifier:
%
keyid:FE:CF:61:36:EF:9B:78:5C:BE:72:B2:58:AA:8D:B3:F9:67:80:98:7C
% DirName:/C=FR/O=TEST/OU=JEREMIE/CN=Autorite de certification
racine Test
% serial:A6:A6:76:4D:F0:1F:36:7D
%
% X509v3 Basic Constraints: critical
% CA:FALSE
% X509v3 Key Usage:
% Digital Signature
% X509v3 Extended Key Usage:
% TLS Web Client Authentication
% X509v3 Subject Alternative Name:
% DNS:diogene.jeremie.int, email:[EMAIL PROTECTED]
% Signature Algorithm: sha1WithRSAEncryption
% ...
Thank you for your help.
Best regards,
--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Cert Serial number
Hello, > how do i convert ASN1_INTEGER to either an int or long. WARNING: asn1 integers may be bigger than int or long! Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Cert Serial number
Hi,how do i convert ASN1_INTEGER to either an int or long.thanks ! _ See what you’re getting into…before you go there. http://newlivehotmail.com
Re: Revoking a certificate using only a serial number?
Olaf Gellert wrote: Hi Joe, Joe Gluck wrote: Does anyone know how can I revoke a certificate, even if I don't have the certificate file anymore, (using openssl) can I just update the index.txt line associated with this certificate, change the V to R and add the revocation date? If this should work does anyone have already a script that does that? Or can some one help with the exact format of the index.txt file. Yes, that's the way: Just change V to R and add a revocation date. BTW, the revocation date is in ASN1_UTCTIME-Format, which is YYMMDDHHMMSSZ (example: "060728115600Z"). If you'll revocate the cert before the year 2050. ;) [...] Hope it helps, Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Re: Revoking a certificate using only a serial number?
Hi Joe, Joe Gluck wrote: Does anyone know how can I revoke a certificate, even if I don't have the certificate file anymore, (using openssl) can I just update the index.txt line associated with this certificate, change the V to R and add the revocation date? If this should work does anyone have already a script that does that? Or can some one help with the exact format of the index.txt file. Yes, that's the way: Just change V to R and add a revocation date. Then issue a new CRL. You might inspect the CRL afterward with openssl crl -in crlfile.pem -text and you should see that the serial number of the revoked certificate is listed in the CRL. Cheers, Olaf -- Dipl.Inform. Olaf Gellert PRESECURE (R) Senior Researcher, Consulting GmbH Phone: (+49) 0700 / PRESECURE [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Revoking a certificate using only a serial number?
Does anyone know how can I revoke a certificate, even if I don't have the certificate file anymore, (using openssl) can I just update the index.txt line associated with this certificate, change the V to R and add the revocation date? If this should work does anyone have already a script that does that? Or can some one help with the exact format of the index.txt file. Thanks, Joe
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
Bonjour,
Hodie pr. Kal. Mar. MMVI est, Mark H. Wood scripsit:
> I think that part of the difficulty here is the words used. Our
> experience in other areas is overwhelmingly in favor of "serial number"
> being a sample from a counter that starts at 0 or 1 and is incremented by
> 1 every time it's consulted.
That's not really incompatible with something random, from the
outside. Just keep an internal counter, pack it properly into a
128bit structure, encrypt it with an AES key, et voilà, you have a
random serial number, and you're sure you won't have any duplicate.
A command-line version (for the CA.{pl,sh} utility) could be this
script:
- genserial.sh
#! /bin/sh
COUNTER=`cat counter`
echo -n $COUNTER | openssl enc -K "`od -t x1 -A n aeskey.bin | sed 's/ //g'`"
-aes-128-ecb -iv | od -t x1 -A n | sed 's/ //g' > serial
echo "obase=16; ibase=16; $COUNTER+1" | bc > counter
-
For this to work, you have to generate a random AES key:
dd if=/dev/urandom of=aeskey.bin bs=1 count=16
and initialize your counter file:
echo "1" > counter (or any value you want)
Call this script to generate a serial number based on the counter, and
increment the counter for the next one. Just tell 'openssl ca' to use
the generated serial, as what is done by default by CA.{pl,sh}.
The iv parameter value is not important, because we use the ECB mode,
but the software needs one to be set, so just make it happy.
This simple script doesn't allow you to generate 2^128 different
serial numbers, you'll only get 16^16 different ones, but for a
home-made CA, that should be enough.
> So we see a field described as a serial
> number and ask why it isn't behaving properly. It's too bad the standard
> calls this attribute a "serial number" rather than, say, "certificate
> unique identifier", but the term is fixed now.
The standard goes back to 1988 for the final X.509 v1, and at that
time, the described X.509 collision attack didn't exist.
Then, somewhere between 1988 and 1997, X.509v2 came in, adding the
subjectUniqueIdentifier field (a UniqueIdentifier is a BIT STRING),
which was replaced in 1997 (X.509v3) by the subjectKeyIdentifier
extension.
The subjectUniqueIdentifier and subjectKeyIdentifier are really meant
to be unique by themselves (wether it's truely unique or not is left
to the implementor), but the serialNumber is not unique alone, by
definition.
--
Erwann ABALEA <[EMAIL PROTECTED]>
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think that part of the difficulty here is the words used. Our experience in other areas is overwhelmingly in favor of "serial number" being a sample from a counter that starts at 0 or 1 and is incremented by 1 every time it's consulted. So we see a field described as a serial number and ask why it isn't behaving properly. It's too bad the standard calls this attribute a "serial number" rather than, say, "certificate unique identifier", but the term is fixed now. - -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Open-source executable: $0.00. Source: $0.00 Control: priceless! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iD8DBQFEBFyts/NR4JuTKG8RAvwvAJkBaF0r/EWrlN94kzBXyhdYDukKLQCfVOIr P337Skc1EMAy4i1wowAXiDQ= =nhvt -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
On Sun, Feb 26, 2006, Dr. Stephen Henson wrote: > On Sun, Feb 26, 2006, Erwann ABALEA wrote: > > > The CA has the possibility to change the name of the issued > > certificate, by adding a random element (a kind of serial number), but > > this isn't usually well percieved (the customer always asks for > > clarification about this random stuff added to his identity), and it > > prevents an end-user to renew a certificate with the same exact > > identity (since this will render the counter-measure useless). > > > > > > >From my understanding of the collision a non-critical extension would be > another place but people would of course ask what it was for. > My recollection of the collision construction was faulty. Non critical extensions wouldn't do because they would appear after the public key. The construction only needs to be able to predict everything before the public key portion of a certificate: it can use whatever the CA provides afterwards as long as it is the same in the two certificates. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
On Sun, Feb 26, 2006, Erwann ABALEA wrote: > Bonjour, > > Hodie IV Kal. Mar. MMVI est, Dr. Stephen Henson scripsit: > [... about serial numbers ...] > > Some CAs choose consecutive values, other what look like random values of > > hashes. > > > > One commercial reason for not using consecutive values is that competitors > > can > > work out how many certificates you've issued... > > One good technical reason to choose "random" serial numbers was > demonstrated by the a paper written by Lenstra, Wang, and Weger > (http://eprint.iacr.org/2005/067). The point here is that if the > attacker can "predict" the content of a certificate, he can carefully > generate a public key so that the signature of a certificate can be > used on another certificate with another identity and public key. This > attack is based on flaws on MD5 demonstrated in summer 2004. SHA1 is > now under attack, and until the SHA2 series is well understood by a > large proportion of the installed software base, CAs are "forced" to > use SHA1... > See also: http://www.win.tue.nl/~bdeweger/CollidingCertificates/ > Just to add that that version of the attack can only generate colliding certificates which are identical other than the public keys. > The CA has the possibility to change the name of the issued > certificate, by adding a random element (a kind of serial number), but > this isn't usually well percieved (the customer always asks for > clarification about this random stuff added to his identity), and it > prevents an end-user to renew a certificate with the same exact > identity (since this will render the counter-measure useless). > > >From my understanding of the collision a non-critical extension would be another place but people would of course ask what it was for. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
Bonjour, Hodie IV Kal. Mar. MMVI est, Dr. Stephen Henson scripsit: [... about serial numbers ...] > Some CAs choose consecutive values, other what look like random values of > hashes. > > One commercial reason for not using consecutive values is that competitors can > work out how many certificates you've issued... One good technical reason to choose "random" serial numbers was demonstrated by the a paper written by Lenstra, Wang, and Weger (http://eprint.iacr.org/2005/067). The point here is that if the attacker can "predict" the content of a certificate, he can carefully generate a public key so that the signature of a certificate can be used on another certificate with another identity and public key. This attack is based on flaws on MD5 demonstrated in summer 2004. SHA1 is now under attack, and until the SHA2 series is well understood by a large proportion of the installed software base, CAs are "forced" to use SHA1... See also: http://www.win.tue.nl/~bdeweger/CollidingCertificates/ The CA has the possibility to change the name of the issued certificate, by adding a random element (a kind of serial number), but this isn't usually well percieved (the customer always asks for clarification about this random stuff added to his identity), and it prevents an end-user to renew a certificate with the same exact identity (since this will render the counter-measure useless). The only logical, non disturbing, embedded place for some random data is the serial number. Several ways exists to make it random from the outside, and still make sure each serial number is unique among a CA. -- Erwann ABALEA <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
On So, 26 Feb 2006, Dr. Stephen Henson wrote: [example snipped] > The fairly large random value for serial numbers is designed to avoid that > situation but still allow the more knowledgeable user to override that. > > If you are sure the issuer name and serial number will be unique then you can > choose any value you wish. Fine, that's understandable. > One commercial reason for not using consecutive values is that competitors can > work out how many certificates you've issued... Yeah, the same procedure as with consecutive invoice-numbers indicating the number of clients ;-) Ciao, Georg __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
Bonjour,
Hodie IV Kal. Mar. MMVI est, Kyle Hamilton scripsit:
[...]
> Can you give me a pointer to the several standards that reflect and
> enforce the issuer name + serial number uniqueness? A more
The X.509 says it all.
>From this standard, a CA is a name (not a key, really a name). That
allows you to renew the CA's key (and certificate), and this
key+certificate still belongs to the same CA. Whence, you can revoke
an issued certificate that was signed by an anterior CA key.
This (issuer name, serial number) uniqueness is clearly stated in
chapter 7 ("Public-keys and public-key certificates"):
"serialNumber is an integer assigned by the CA to each certificate. The
value of serialNumber must be unique for each certificate issued by a given
CA (i.e., the issuer name and serial number identify a unique certificate)."
--
Erwann ABALEA <[EMAIL PROTECTED]>
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
On Sun, Feb 26, 2006, Georg Lohrer wrote: > > As I have hopefully understood setting the serial number of a CA to a > distinct number like 1 is good practice. From a technical point of view any > number should as good as another as long as they are unique (as you mentioned > in your post to Kyle). But for a CA? I saw a CA-certificate from Thawte having > a serial number of 1 and a CA-certificate of VeriSign having a perhaps random > number. What will be the best way for a CA? Is there any preferred way? > The problem with OpenSSL by default using '1' and then consecutive numbers was that newboes were following some rather ancient "cookbooks" which came with certain projects using OpenSSL and ended up producing loads of duplicates. Even using the recommended methods (CA.pl) that was still possible. To give you a simple example. As a test case someone might use the default values for a certificate in the fields and put something like "test" in the fields without a default. They might install that certificate or install it on a radnsom colllection of machines. If they then get it wrong and try again later with the same values, which would be a duplicate serial number in the two CAs for a start. If the two CAs had issued end user certificates you'd get the situation where apparently bizarre errors such as certificate signature failures would occur: because the other CA public key was used to verify the signatures on certificates. The fairly large random value for serial numbers is designed to avoid that situation but still allow the more knowledgeable user to override that. If you are sure the issuer name and serial number will be unique then you can choose any value you wish. Some CAs choose consecutive values, other what look like random values of hashes. One commercial reason for not using consecutive values is that competitors can work out how many certificates you've issued... Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
On Sun, Feb 26, 2006, Kyle Hamilton wrote: > On 2/25/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > > > > > It is the combination of issuer name + serial number which must be unique in > > general: that's enforced by several standards. > > > > Certain pieces of software assumes that issuer name + serial number can be > > used as a unique index and can cause all manner of problems if that turns > > out > > not to be the case. > > This raises the potential for a Denial of Service capability enforced > by the standards. (In fact, NSS got hit by this DoS issue several > years back, when an untrusted certificate with the same > IssuerName+SerialNumber was put in the certificate store without any > trust, and was used to verify certificates signed with that AKI... the > net effect being that certs signed by the trusted issuer couldn't be > verified.) > Yes implementations have to be careful they don't make assumptions about untrusted certificates which may deliberately break the rules. > > An obvious consequence is that a CA cannot sign different certificates with > > the same serial number. > > > > Whether a CA can sign a certificate with its own serial number depends on > > the > > CA. > > > > If the CA has the same issuer name and subject name then it has > > effectively "issued itself" (the term "self issued" is sometimes used) so it > > cannot sign a further certificate with its serial number. > > > > In the case of CAs with different issuer and subject names that isn't the > > case > > and it can issue a certificate with its own serial number. > > > > Steve. > > Can you give me a pointer to the several standards that reflect and > enforce the issuer name + serial number uniqueness? > If you look for the "serialNumber" definition in many certificate texts it is either mentioned or implied. It is one of those things that is considered so fundamental it is often taken for granted. The uniqueness for a single CA is explicitly stated by 4.1.2.2 in RFC3280. There are several cases where it is implied by virtue of the fact that a certificate identifier is issuer name and serial number. If that was ambiguous certain protocols wouldn't work. CRLs are one example. AKID is another. S/MIME is another. The signer certificate(s) for signedData and the recipient certificate(s) for enveloped data are identified by issuer name and serial number. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
On 2/25/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > On Sat, Feb 25, 2006, Kyle Hamilton wrote: > > > "serialNumber: A unique positive integer." At least I think. > > > > The type of serialNumber that should be accepted doesn't place any limits on > the sign. > > RFC3280 places restrictions on what a CA should generate. It says it must be > "non-negative" at one point which is >= 0. In another place it states that > zero > or negative in invalid i.e. >0 is valid. ooh. Opportunity for errata. > > > > Issuing certificates with duplicate issuer and serial numbers is illegal > > > and > > > can cause strange problems which are difficult to diagnose. > > > > let's see... you're talking about the authorityKeyIdentifier? I > > thought that that went up 2 steps up the tree and then gave a serial > > number of cert issued by that CA. > > > > And I'm trying to parse this more effectively, can you tell me if you > > meant something other than: "A CA that issues certificates cannot > > issue a certificate that has the same serial number as its own serial > > number"? This suggests that the CA's serial number is imported into > > the context of its own signatures' serial numbers, even when it's a > > sub-CA? > > > > It is the combination of issuer name + serial number which must be unique in > general: that's enforced by several standards. > > Certain pieces of software assumes that issuer name + serial number can be > used as a unique index and can cause all manner of problems if that turns out > not to be the case. This raises the potential for a Denial of Service capability enforced by the standards. (In fact, NSS got hit by this DoS issue several years back, when an untrusted certificate with the same IssuerName+SerialNumber was put in the certificate store without any trust, and was used to verify certificates signed with that AKI... the net effect being that certs signed by the trusted issuer couldn't be verified.) > An obvious consequence is that a CA cannot sign different certificates with > the same serial number. > > Whether a CA can sign a certificate with its own serial number depends on the > CA. > > If the CA has the same issuer name and subject name then it has > effectively "issued itself" (the term "self issued" is sometimes used) so it > cannot sign a further certificate with its serial number. > > In the case of CAs with different issuer and subject names that isn't the case > and it can issue a certificate with its own serial number. > > Steve. Can you give me a pointer to the several standards that reflect and enforce the issuer name + serial number uniqueness? A more appropriate way of handling it would be issuer name + hash of pubkey + serial number -- even though this might screw up other parts of the authentication/verification protocol (esp. in the case of a CA rekey), it also allows for completely dead CA structures to not interfere with live ones. -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
> let's see... you're talking about the authorityKeyIdentifier? I > thought that that went up 2 steps up the tree and then gave a serial > number of cert issued by that CA. No, it identifies the key that is signing the actual cert (or CRL). A CA's subject key identifier (SKI) gets populated as the AKI into everything it signs. /r$ -- SOA Appliance Group IBM Application Integration Middleware __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
On Sat, Feb 25, 2006, Kyle Hamilton wrote: > On 2/25/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > > It was introduced as a bug fix to stop OpenSSL producing invalid > > certificates > > under certain circumstances. > > > > A clarification indicated that zero was considered an invalid serial number. > > "serialNumber: A unique positive integer." At least I think. > The type of serialNumber that should be accepted doesn't place any limits on the sign. RFC3280 places restrictions on what a CA should generate. It says it must be "non-negative" at one point which is >= 0. In another place it states that zero or negative in invalid i.e. >0 is valid. > > Issuing certificates with duplicate issuer and serial numbers is illegal and > > can cause strange problems which are difficult to diagnose. > > let's see... you're talking about the authorityKeyIdentifier? I > thought that that went up 2 steps up the tree and then gave a serial > number of cert issued by that CA. > > And I'm trying to parse this more effectively, can you tell me if you > meant something other than: "A CA that issues certificates cannot > issue a certificate that has the same serial number as its own serial > number"? This suggests that the CA's serial number is imported into > the context of its own signatures' serial numbers, even when it's a > sub-CA? > It is the combination of issuer name + serial number which must be unique in general: that's enforced by several standards. Certain pieces of software assumes that issuer name + serial number can be used as a unique index and can cause all manner of problems if that turns out not to be the case. An obvious consequence is that a CA cannot sign different certificates with the same serial number. Whether a CA can sign a certificate with its own serial number depends on the CA. If the CA has the same issuer name and subject name then it has effectively "issued itself" (the term "self issued" is sometimes used) so it cannot sign a further certificate with its serial number. In the case of CAs with different issuer and subject names that isn't the case and it can issue a certificate with its own serial number. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
On So, 26 Feb 2006, Dr. Stephen Henson wrote: > On Sun, Feb 26, 2006, Georg Lohrer wrote: > > > > > Even if I create an explicit serial-file it won't be used for the 'req' > > command (tested with strace). > > > > Any ideas what I'm doing wrong? Or is the man-page wrong? > > > > The manual page needs updating. It now uses a random serial number unless a > serial number is given explicitly. This was to reduce the chance of duplicate > issuer names and serial numbers. Ah yes; I scrutinized through the code and saw that the current time will be used for forming the random number (crypto/bn/bn_rand.c). As I have hopefully understood setting the serial number of a CA to a distinct number like 1 is good practice. From a technical point of view any number should as good as another as long as they are unique (as you mentioned in your post to Kyle). But for a CA? I saw a CA-certificate from Thawte having a serial number of 1 and a CA-certificate of VeriSign having a perhaps random number. What will be the best way for a CA? Is there any preferred way? Ciao, Georg __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
On 2/25/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > It was introduced as a bug fix to stop OpenSSL producing invalid certificates > under certain circumstances. > > A clarification indicated that zero was considered an invalid serial number. "serialNumber: A unique positive integer." At least I think. > Issuing certificates with duplicate issuer and serial numbers is illegal and > can cause strange problems which are difficult to diagnose. let's see... you're talking about the authorityKeyIdentifier? I thought that that went up 2 steps up the tree and then gave a serial number of cert issued by that CA. And I'm trying to parse this more effectively, can you tell me if you meant something other than: "A CA that issues certificates cannot issue a certificate that has the same serial number as its own serial number"? This suggests that the CA's serial number is imported into the context of its own signatures' serial numbers, even when it's a sub-CA? > If you want to keep the previous behaviour when you use "openssl req -x509" > you > have to explicitly use the -set_serial option. Thank you for the workaround. > The other case is where a serial number file is created. To keep the old > behaviour you need to explicitly create a serial number file with the > appropriate value. ...or just use the one I already have, I would presume? Thanks for your help, Dr. Henson. -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
On Sat, Feb 25, 2006, Kyle Hamilton wrote: > Is there a way to specify the old behavior? (I'm collecting as much > information as I can on current practice and putting it all together > -- the overloading of 'authorityKeyIdentifier' is only part of the > problem with current X.509 practice, and that overloading creates a > situation where software makers introduce incompatible changes -- I've > got logging software and log processing software that relies on the > former, serial functionality.) > It was introduced as a bug fix to stop OpenSSL producing invalid certificates under certain circumstances. A clarification indicated that zero was considered an invalid serial number. Issuing certificates with duplicate issuer and serial numbers is illegal and can cause strange problems which are difficult to diagnose. If you want to keep the previous behaviour when you use "openssl req -x509" you have to explicitly use the -set_serial option. The other case is where a serial number file is created. To keep the old behaviour you need to explicitly create a serial number file with the appropriate value. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
Is there a way to specify the old behavior? (I'm collecting as much information as I can on current practice and putting it all together -- the overloading of 'authorityKeyIdentifier' is only part of the problem with current X.509 practice, and that overloading creates a situation where software makers introduce incompatible changes -- I've got logging software and log processing software that relies on the former, serial functionality.) -Kyle H On 2/25/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > On Sun, Feb 26, 2006, Georg Lohrer wrote: > > > > > Even if I create an explicit serial-file it won't be used for the 'req' > > command (tested with strace). > > > > Any ideas what I'm doing wrong? Or is the man-page wrong? > > > > The manual page needs updating. It now uses a random serial number unless a > serial number is given explicitly. This was to reduce the chance of duplicate > issuer names and serial numbers. > > Steve. > -- > Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage > OpenSSL project core developer and freelance consultant. > Funding needed! Details on homepage. > Homepage: http://www.drh-consultancy.demon.co.uk > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
On Sun, Feb 26, 2006, Georg Lohrer wrote: > > Even if I create an explicit serial-file it won't be used for the 'req' > command (tested with strace). > > Any ideas what I'm doing wrong? Or is the man-page wrong? > The manual page needs updating. It now uses a random serial number unless a serial number is given explicitly. This was to reduce the chance of duplicate issuer names and serial numbers. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
openssl req -x509 does not create serial-number 0
Hi, if I use the command: $ /usr/local/bin/openssl req -x509 -new -days 30 -key ./cacert.key -out ./cacert.pem -outform PEM to create a self-signed root-certificate the 'man req' page says: -x509 this option outputs a self signed certificate instead of a certificate request. This is typically used to generate a test certificate or a self signed root CA. The extensions added to the certificate (if any) are specified in the configuration file. Unless specified using the set_serial option 0 will be used for the serial number. So I expected a serial-number of 0, but get a: $ /usr/local/bin/openssl x509 -serial -noout -in cacert.pem serial=806E141592B2EFF9 If I use the '-set_serial' I will get the expected serial number of course. The automatically used /usr/local/ssl/openssl.cnf does only these serial related lines: [ ca ] default_ca = CA_default# The default ca section [ CA_default ] dir = ./demoCA # Where everything is kept certs = $dir/certs# Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database= $dir/index.txt# database index file. #unique_subject = no# Set to 'no' to allow creation of # several ctificates with same # subject. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number Even if I create an explicit serial-file it won't be used for the 'req' command (tested with strace). Any ideas what I'm doing wrong? Or is the man-page wrong? Ciao, Georg __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
x509_get_serialNumber can't get me the serial number in base 64
Hi, I have the following code char serial[300]; i2a_ASN1_INTEGER(bio, X509_get_serialNumber(x509)); n = BIO_read(bio, serial, min(BIO_pending(bio), 299)); n = max(n, 0); serial[n] = 0; BIO_flush(bio); And I get the following result inside serial 3030303031303030303030303030303030313134 So those are the ASCIIs of the following number 1114 ß that is base 64 So how can I get that base 64 number, do I have to manually parse the array serial, make pairs of numbers, then turn those numbers into a byte, and then put those bytes into an array of bytes, then convert that array of bytes to base 64? Or is there a shorter way to get to that base 64 number Thanks in advance Isaac Briseño Yahoo! FareChase - Search multiple travel sites in one click.
FW: CA generation/certificate serial number
Hi, Sorry if this is a second post, but the first one should not have reached the openssl mail server due to the attachment. Move test-2-bad.crt to test-2-bad.pem Hi, thanks for your answer, But the signature is OK when creating the X509 certificate signing it and verifying it. (the dump is also ok) This is a problem with the serial number (ASN1) when NOT setting it in the X509 struct and saving in a file and reloading it from the file for a verification. My certificate is a bad one because i did not set the serial number. The question is: should the serial number be set to a defualt one (0x00)? Morevover, i found that the verify function is not working properly. I try to verify, and the return is OK whereeas it should not. [EMAIL PROTECTED] Atempo-Tina]$ LD_LIBRARY_PATH=/usr/local/ossl-0.9.8/lib /netsecureone/dev/openssl/ossl-0.9.8x/openssl-0.9.8/apps/openssl verify -purpose any -verbose -CAfile testCA-1.crt test-2-bad.crt INFO: X509_VRFY_PARM: inh_flags: 1, flags: 0, purpose: 7, trust: 0, depth: -1 INFO: argc: 1 test-2-bad.crt: INFO: vflags value: 0, purpose value: -1 INFO X509stack ptr: uchain: (nil), tchain: (nil) INFO: x value: 0x80b0cf0 OK My certificate has no Key extension (see attached file test-2-bad.crt). If i us the X509_check_purpose() function things are ok (i could detect SSL settings). Regards, Fred PS: i just do CSR (X509_REQ), CRT (X509), sign using X509_sign(), and verify using X509_verify(). (my code is based on apps/req.c, appas/x509.c apps/verify.c and other file in the demo directory) If required i should be able to provide it. -Original Message- From: Nils Larsch [mailto:[EMAIL PROTECTED] Sent: Wed 8/31/2005 12:21 AM To: openssl-users@openssl.org Cc: Subject:Re: CA generation/certificate serial number Frédéric Donnat wrote: > Hi, > > Sorry for the mistake (nothing to deal with openssl.cnf file). I was just > looking for ca.txt file. > > Is it normal behavior of openssl to be able to view a certificate without > serial number using (without any error mentioned): > openssl x509 -in some_cert_without_sn.pem -text > But to be unable to verify it using: > openssl verify -CAfile some_cert_without_sn.pem some_cert_without_sn.pem > > > Sample: (attached self-sign cert name pipo-bad.pem) hmm, the attached certificate as has a serial number it's 0x0 > > [EMAIL PROTECTED] simple]$ LD_LIBRARY_PATH=/usr/local/ossl-0.9.8/lib > /usr/local/ossl-0.9.8/bin/openssl verify -verbose -CAfile pipo-bad.pem > pipo-bad.pem > pipo-bad.pem: /C=UK/CN=OpenSSL Group > error 7 at 0 depth lookup:certificate signature failure > 18588:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:218: > 18588:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP > lib:a_verify.c:168: well the signature really seems to be wrong. How did you create the certificate ? Cheers, Nils __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] test-2-bad.pem Description: test-2-bad.pem
Re: CA generation/certificate serial number
Frédéric Donnat wrote: Hi, Sorry for the mistake (nothing to deal with openssl.cnf file). I was just looking for ca.txt file. Is it normal behavior of openssl to be able to view a certificate without serial number using (without any error mentioned): openssl x509 -in some_cert_without_sn.pem -text But to be unable to verify it using: openssl verify -CAfile some_cert_without_sn.pem some_cert_without_sn.pem Sample: (attached self-sign cert name pipo-bad.pem) hmm, the attached certificate as has a serial number it's 0x0 [EMAIL PROTECTED] simple]$ LD_LIBRARY_PATH=/usr/local/ossl-0.9.8/lib /usr/local/ossl-0.9.8/bin/openssl verify -verbose -CAfile pipo-bad.pem pipo-bad.pem pipo-bad.pem: /C=UK/CN=OpenSSL Group error 7 at 0 depth lookup:certificate signature failure 18588:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:218: 18588:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:168: well the signature really seems to be wrong. How did you create the certificate ? Cheers, Nils __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
CA generation/certificate serial number
Hi, Sorry for the mistake (nothing to deal with openssl.cnf file). I was just looking for ca.txt file. Is it normal behavior of openssl to be able to view a certificate without serial number using (without any error mentioned): openssl x509 -in some_cert_without_sn.pem -text But to be unable to verify it using: openssl verify -CAfile some_cert_without_sn.pem some_cert_without_sn.pem Sample: (attached self-sign cert name pipo-bad.pem) [EMAIL PROTECTED] simple]$ LD_LIBRARY_PATH=/usr/local/ossl-0.9.8/lib /usr/local/ossl-0.9.8/bin/openssl verify -verbose -CAfile pipo-bad.pem pipo-bad.pem pipo-bad.pem: /C=UK/CN=OpenSSL Group error 7 at 0 depth lookup:certificate signature failure 18588:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:218: 18588:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:168: I'm using openssl 0.9.8. regards, Fred -Original Message- From: Frédéric Donnat Sent: Mon 8/29/2005 11:51 AM To: openssl-users@openssl.org Cc: Subject:/usr/local/ossl-0.9.8/ssl/openssl.cnf Hi all, Could someone telle where i can find the following file: ca.txt I'm reading opthe HOWTO and i see the following comment (cetificates.txt): This is NOT the recommended way to create a" CA certificate, see ca.txt." regards, Fred __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] pipo-bad.pem Description: pipo-bad.pem
Re: AW: Max length of serial number
[EMAIL PROTECTED] writes: as far as I read the text from the RFC, they are talkin about non-negative numbers. So the range is from 0 to 2^(159)-1 because the one bit missing indicates a negative number. True. That doesn't change my point, though :-). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
AW: Max length of serial number
Richard, as far as I read the text from the RFC, they are talkin about non-negative numbers. So the range is from 0 to 2^(159)-1 because the one bit missing indicates a negative number. Best regards Thomas Beckmann > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag von Richard Levitte > Gesendet: Montag, 18. Juli 2005 15:42 > An: openssl-users@openssl.org > Cc: Jorey Bump > Betreff: Re: Max length of serial number > > > Jorey Bump writes: > > > And RFC 3280 has this to say: > > > > 4.1.2.2 Serial number > > > >The serial number MUST be a positive integer assigned by > the CA to > >each certificate. It MUST be unique for each > certificate issued by a > >given CA (i.e., the issuer name and serial number > identify a unique > >certificate). CAs MUST force the serialNumber to be a > non-negative > >integer. > > > >Given the uniqueness requirements above, serial numbers can be > >expected to contain long integers. Certificate users > MUST be able to > >handle serialNumber values up to 20 octets. Conformant > CAs MUST NOT > >use serialNumber values longer than 20 octets. > > > >Note: Non-conforming CAs may issue certificates with > serial numbers > >that are negative, or zero. Certificate users SHOULD be > prepared to > >gracefully handle such certificates. > > > > I guess this limits serial numbers to 20 numeric characters, > > You do realise, don't you, that 20 octets isn't the same as > 20 numeric > characters? > > This means that your serial number span is 0 to 2^(8*20)-1, > which is 2^160 > different value. That's enough to give every atom in the > known universe a > few certs each. I bet that's enough for your purposes :-). > > Cheers, > Richard > > - > Please consider sponsoring my work on free software. > See http://www.free.lp.se/sponsoring.html for details. > > -- > Richard Levitte [EMAIL PROTECTED] >http://richard.levitte.org/ > > "When I became a man I put away childish things, including > the fear of childishness and the desire to be very grown up." >-- C.S. Lewis > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Max length of serial number
Jorey Bump writes: And RFC 3280 has this to say: 4.1.2.2 Serial number The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. Given the uniqueness requirements above, serial numbers can be expected to contain long integers. Certificate users MUST be able to handle serialNumber values up to 20 octets. Conformant CAs MUST NOT use serialNumber values longer than 20 octets. Note: Non-conforming CAs may issue certificates with serial numbers that are negative, or zero. Certificate users SHOULD be prepared to gracefully handle such certificates. I guess this limits serial numbers to 20 numeric characters, You do realise, don't you, that 20 octets isn't the same as 20 numeric characters? This means that your serial number span is 0 to 2^(8*20)-1, which is 2^160 different value. That's enough to give every atom in the known universe a few certs each. I bet that's enough for your purposes :-). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Max length of serial number
Jorey Bump wrote: There is one caveat: the number of characters must be even: unable to load number from /etc/ssl/CA/serial error while loading serial number 3068:error:0D066091:asn1 encoding routines:a2i_ASN1_INTEGER:odd number of chars:f_int.c:162: Therefore, I needed to modify my command: # example: 2005071711520001 (16 char, must be even # of chars) echo $(date +%Y%m%d%H%M)0001 > serial And RFC 3280 has this to say: 4.1.2.2 Serial number The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. Given the uniqueness requirements above, serial numbers can be expected to contain long integers. Certificate users MUST be able to handle serialNumber values up to 20 octets. Conformant CAs MUST NOT use serialNumber values longer than 20 octets. Note: Non-conforming CAs may issue certificates with serial numbers that are negative, or zero. Certificate users SHOULD be prepared to gracefully handle such certificates. I guess this limits serial numbers to 20 numeric characters, and I assume this includes leading zeroes, unless the asn1 encoding routine strips them. Unfortunately, this limits the life of my CA to 99,997,994,928,288,479,998 signed certficates, using the example I've given above. ;) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Max length of serial number
Todd Wease wrote: On Sun, 2005-07-17 at 12:03 -0400, Jorey Bump wrote: What is the maximum length (if string) or size (if number) of a serial number? I am using the current datetime to set the initial serial number for my CA to provide a reasonable measure of uniqueness: # example: 200507171152001 SERIALINIT=$(date +%Y%m%d%H%M)001 echo $SERIALINIT > serial Do I need to be concerned with the number of characters or the number of bits used to represent the serial number? Is there an RFC that defines this? I found this in RFC 2459 (http://www.faqs.org/rfcs/rfc2459.html) *** 4.1 Basic Certificate Fields The X.509 v3 certificate basic syntax is as follows. For signature calculation, the certificate is encoded using the ASN.1 distinguished encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, value encoding system for each element. ... CertificateSerialNumber ::= INTEGER ... *** and then I found this (http://gost.isi.edu/brian/security/asn1.html) ... And that's all that we need. This second specification introduces us to another primitive, INTEGER, which is exactly what it sounds like, an integer. The difference between this integer and that which resides on most machines is that this one is arbitrarily large: the ASN.1 encoding for integer allows for integers of whatever size. ... Here is the ASN.1 website - http://asn1.elibel.tm.fr/ Thanks, Todd. There is one caveat: the number of characters must be even: unable to load number from /etc/ssl/CA/serial error while loading serial number 3068:error:0D066091:asn1 encoding routines:a2i_ASN1_INTEGER:odd number of chars:f_int.c:162: Therefore, I needed to modify my command: # example: 2005071711520001 (16 char, must be even # of chars) echo $(date +%Y%m%d%H%M)0001 > serial __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Max length of serial number
On Sun, 2005-07-17 at 12:03 -0400, Jorey Bump wrote: > What is the maximum length (if string) or size (if number) of a serial > number? > > I am using the current datetime to set the initial serial number for my > CA to provide a reasonable measure of uniqueness: > > # example: 200507171152001 > SERIALINIT=$(date +%Y%m%d%H%M)001 > echo $SERIALINIT > serial > > Do I need to be concerned with the number of characters or the number of > bits used to represent the serial number? Is there an RFC that defines this? > I found this in RFC 2459 (http://www.faqs.org/rfcs/rfc2459.html) *** 4.1 Basic Certificate Fields The X.509 v3 certificate basic syntax is as follows. For signature calculation, the certificate is encoded using the ASN.1 distinguished encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, value encoding system for each element. ... CertificateSerialNumber ::= INTEGER ... *** and then I found this (http://gost.isi.edu/brian/security/asn1.html) ... And that's all that we need. This second specification introduces us to another primitive, INTEGER, which is exactly what it sounds like, an integer. The difference between this integer and that which resides on most machines is that this one is arbitrarily large: the ASN.1 encoding for integer allows for integers of whatever size. ... Here is the ASN.1 website - http://asn1.elibel.tm.fr/ Todd __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Max length of serial number
What is the maximum length (if string) or size (if number) of a serial number? I am using the current datetime to set the initial serial number for my CA to provide a reasonable measure of uniqueness: # example: 200507171152001 SERIALINIT=$(date +%Y%m%d%H%M)001 echo $SERIALINIT > serial Do I need to be concerned with the number of characters or the number of bits used to represent the serial number? Is there an RFC that defines this? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl ocsp request , serial number
In message <[EMAIL PROTECTED]> on Wed, 6 Jul 2005 09:07:23 -0700, "Choudhary, Bimalendu" <[EMAIL PROTECTED]> said: bchoudhary> 2) When I send the serial number 0x81 the der encoded bchoudhary>serial number is bchoudhary> bchoudhary> 02 02 00 81 bchoudhary> bchoudhary> 4) When I send the serial number 0x8111 the der encoded bchoudhary>serial number is bchoudhary> bchoudhary> 02 03 00 81 11 bchoudhary> bchoudhary> The problem here is that in case 2) and 4) there is a bchoudhary> extra byte 00 appended in front of the actual serial bchoudhary> number given in the command line. bchoudhary> bchoudhary> Can any one tell me why the length is being increased and bchoudhary> an extra 00 is added in front of the serial number in this bchoudhary> two cases. bchoudhary> bchoudhary> It happens foe any serial number starting with hex digit 8 bchoudhary> or above and number of digit in the serial number is even. ASN.1 Complete (downloadable from http://www.oss.com/asn1/larmouth.html), Section 3.3 (Encoding an INTEGER value) explains it. Basically, the integer is a 2-complement value. This means '02 01 81' would be interpreted as (decimal) -127, while '02 02 00 81' is correctly interpreted as (decimal) 129. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
openssl ocsp request , serial number
Hi, I am using an OCSP command to sned ocsp request to my program using following command Openssl ocsp -serial 0x80 -issuer issuer.pem -text -url http://myprogram When I see the actual DER encoded request which openssl sends, I found different behaviour for different serial numbers. 1) When I send the serial number -serial 0x8 the der encoded serial number is 02 01 08 2) When I send the serial number 0x81 the der encoded serial number is 02 02 00 81 3) When I send the serial number 0x811 the der encoded serial number is 02 02 08 11 4) When I send the serial number 0x8111 the der encoded serial number is 02 03 00 81 11 The problem here is that in case 2) and 4) there is a extra byte 00 appended in front of the actual serial number given in the command line. Can any one tell me why the length is being increased and an extra 00 is added in front of the serial number in this two cases. It happens foe any serial number starting with hex digit 8 or above and number of digit in the serial number is even. Thanks Bimalendu -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas J. Hruska Sent: Wednesday, July 06, 2005 11:51 AM To: openssl-users@openssl.org Subject: Re: BC-32 dll [EMAIL PROTECTED] wrote: > Hi there, I've finaly compiled 0.9.8 under BCB win32 (Yay!) and now wondering is there any way do make dlls instead of .libs? If you are using the default build of OpenSSL: http://www.slproweb.com/products/Win32OpenSSL.html It comes with pre-built binaries and libraries of the default build of OpenSSL to link against for Borland Builder 4/5/6 (AND also works with the free command line tools). This project typically lags behind OpenSSL by a couple days. Thomas Hruska __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Get Serial number from a cert
On Monday May 23rd 2005 Angel Martinez Gonzalez wrote:
> I want to get the serial number from a certificate.
>
> ...
>
> FILE *fp;
> X509 *cert;
> int serialNumber;
> ASN1_INTEGER *bs;
>
> if (!(fp = fopen(CERTIFICADO_TTP, "r")))
> printf ("Error\n");
>
> if (!(cert = PEM_read_X509(fp, NULL, NULL, NULL)))
> printf ("Error\n");
> fclose(fp);
>
> bs = X509_get_serialNumber(cert);
>
> printf ("Serial number: %s \n", bs->data);
>
> What is wrong?. Thanks.
Nothing, but the serial number is basically an unformatted string of
bytes, that can theoretically be arbitrarily long. You have to "format"
it yourself. The following displays "short" (4 bytes or less) serial
numbers as "numerical" and others as hexadecimal; both include the sign:
char * SerialNumberFromASN1(ASN1_INTEGER *serial_number)
{
char buf[64];
string result;
long l;
int i;
const char *neg;
if (serial_number->length <= 4) {
l=ASN1_INTEGER_get(serial_number);
if (l < 0) {
l= -l;
neg ="-";
} else {
neg ="";
}
snprintf(buf, sizeof(buf),"%s%lu", neg, l);
#if 0
/* The OpenSSL format of 'openssl -x509 -text': */
snprintf(buf, sizeof(buf)," %s%lu (%s0x%lx)", neg, l, neg, l);
#endif
result = buf;
} else {
neg = (serial_number->type == V_ASN1_NEG_INTEGER) ? "-" :"";
snprintf(buf, sizeof(buf), "%s", neg);
result += buf;
for (i=0; i < serial_number->length; i++) {
sprintf(buf, "%02X%c", serial_number->data[i], ((i + 1
== serial_number->length) ? '\0' :':'));
result += buf;
}
}
return strdup(buf);
}
--
Marco Roeland
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Get Serial number from a cert
Hello:
I want to get the serial number from a certificate.
I use this function: X509_get_serialNumber().
This function returns a ASN1_INTEGER struct, with the field length, type,
data and flag. I suppose that the serial number is stored in the data field
of the struct. But I can´t get it.
My code is the following:
char *CERTIFICADO_TTP = "cacert.pem";
FILE *fp;
X509 *cert;
int serialNumber;
ASN1_INTEGER *bs;
if (!(fp = fopen(CERTIFICADO_TTP, "r")))
printf ("Error\n");
if (!(cert = PEM_read_X509(fp, NULL, NULL, NULL)))
printf ("Error\n");
fclose(fp);
bs = X509_get_serialNumber(cert);
printf ("Serial number: %s \n", bs->data);
What is wrong?. Thanks.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
serial number file not created in 0.9.7e
Hello all, In 0.9.7d the serial number file is created as follows 1. Create a certificate request openssl req -out ksb_cert_req.pem -new -keyout ksb_priv_key.pem -rand rand_file -subj /C=US/ST=xxx/L=xxx/O=xxx/CN=ca -nodes 2. Create a self signed certificate openssl req -x509 -out ca_cert.pem -new -keyout ca_priv_key.pem -subj /C=US/ST=xxx/L=xxx/O=xxx/CN=req -nodes -passout pass:pass 3. Sign the certificate request using the self signed certificateopenssl x509 -req -passin pass:pass -in ksb_cert_req.pem -CA ca_cert.pem -CAkey ca_priv_key.pem -CAcreateserial -out ksb_cert.pem -days 365 It creates the serial file ca_cert.srl But in 0.9.7e this serial file is not created . What may be the reason? Thanks, Prakash Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
Re: Serial Number
> Yes, you are right, it could be difficult to garantee that the random > serial number will be unique. As an aside, I'm not sure this is such a major hurdle. The CA should be able to look up certs by serial number anyway, and if it can do that efficiently (e.g., you have a Berkeley DB DB_HASH table mapping serial number to filename) then you can use the same mechanism to ensure that random SNs are unique. > Also a digest from timestamp will be more appropriate. Another common choice is MMDDXX where the prefix is the current date, and the XX is some random component. This still gives you the nice property that SN1 > SN2 implies that the first cert was issued after than the second cert (unless the SNs are close), while giving you a large random component. > My question for you is how to write this SN's value when > I sign the CSR? X509_set_serialNumber(x, s); but only if you're doing it in C instead of the CLI level. In fact, getting the ability to set SNs to what I wanted is one reason why I went with some local C programs instead of the standand CLI tools. Bear __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Serial Number
Hi Richard,
Yes, you are right, it could be difficult to garantee that the random
serial number will be unique. Also a digest from timestamp will be
more appropriate.
So suppose I can do something like that with e.g. (Linux)
TIMESTAMP=`date`
SN=`md5sum ${TIMESTAMP}`
My question for you is how to write this SN's value when
I sign the CSR?
Regards
#-
Averroes
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
