Re: [openssl-users] Creating Extended Validation SSL Certificates
Hodie IX Kal. Oct. MMX, Gumbie scripsit: > Can someone explain what is needed to create and EV (Extended >Validation) Certificate? I have been trying to research this and have >found limited information on this. Only one document that was of any help >-àhttp://www.cabforum.org/EV_Certificate_Guidelines.pdf. That's the only necessary document for technical issues. > My issue is with OpenSSL and adding the needed additional OIDs to the >certificate. Using OpenSSL and adding additional OIDs is not sufficient for a certificate to be "EV with a green bar". You need your CA to be integrated in supported browsers as an EV-compliant one, and for this, you need to be audited, have correct validation procedures, have a correct facility, etc. -- Erwann ABALEA Département R&D KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: Creating Extended Validation SSL Certificates
Bonjour, Hodie V Kal. Oct. MMX, Gumbie scripsit: > I apologize to all for not looking into this more, before asking. > It isn't just a matter of adding the proper extensions. The > various browser software actually has the corporate policy OID > hard coded into the browser code. At first glance I would never of > thought this, as the delay to getting your product to the web > market may be a factor. Please be more explicit about "your product". Is "your product" a device? A server? If yes, then the delay is clearly not an issue, an EV certificate can be bought and delivered in 1 or 2 days, if you're ready for the necessary validations (EV stands for Extended Validation). > Again unless you pay outrageous fees for > basically getting a notary seal from one of the certificate CA's > that have their policy already in place or you're out of luck! Outrageous fees? A free SSL certificate is exactly of this value. Zero, as nearly no verification is performed, or they're completely automatic ones (i.e. send a challenge to a predefined email address, wait for the answer, update the database to say 'OK, this guy controls this address'). An EV certificate costs money: - robust facility, with safes, HSM, access controls, guaranteed connectivity (to provide revocation information), redundant sites - trained employees, and employees background screening (done on a regular basis) - up-to-date procedures; you seem to have downloaded the 1.0 version of the guidelines, dated 2007, an 1.2 version is already out, some work is currently done to update it; CAs must follow this work, and be informed about cryptography advances - "enrollment" of the CA on end-user products (some of them require work to be done, some of them require payment) - most sensible operations performed under screening and validation of a notary (namely key ceremonies) - audits performed each year - certificate request validations performed manually (i.e. by humans), with access to different information repositories (some of them may not be free), contact of the entity requesting the certificate, gathering and controlling necessary documents (ID information, for example) - usually using a proprietary software, written by the company itself, with quality controls, certifications, documentation, testing, etc. All this has a price. Try to live in a free world if you want to, but be prepared not to get paid at all. > Again it's not the fact you have to meet the guidelines, my issue > is with the fees places like (no names mentioned) charge for > certificates. I do think they should get paid for work done, but I > don't think the current fees are in proportion with the product / > service provided... I think you should have looked a bit more into it, before complaining :) > Sorry if I offended anyone, No offense, really. (We provide EV certificates, among other things, and everything described above is really done) -- Erwann ABALEA Département R&D KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] OCSP Success even cert alredy expired
Hodie IV Non. Oct. MMX, shizumi scripsit: > i using openssl test tool by using this command > > openssl.exe ocsp -issuer "issuer.pem" -CAfile "CACert.pem" -cert > "Certificate.pem" -url http://192.168.0.235:8080/myCA/publicweb/status/ocsp > > my CACert and issuer cert already expired. If either the CA cert or the user cert has expired, then asking for a revocation status is not necessary, the certificate is not currently valid. X.509 standard says that the CA warrants to maintain information about the status of the certificate during its valitidy period (validity of the issued certificate). > but it still return me "respond > verify OK". i see in my ca server. it show me error "cannot found in > database" Strange. Are you sure you're asking the right CA? Did you use the "-updatedb" option of "openssl ca" command, to delete expired certificates from its database? If yes, then you've got the reason of this message. >From the CA, it's dangerous to reply with an OK status when this certificate can't be found (an unknown status would be better). But in the end, everything has expired, so that's not really a problem. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: How to disable index and serial?
Hodie III Id. Ian. MMXI, Peter Sylvester scripsit: > by using the command x509 and not ca for example. > you can use a serial number based on a date > seconds plus processid for example) to guarantee > uniqueness. More on this. A serial number MUST be unique (by X.509 design), and SHOULD be random (best practices, to avoid attacks with non collision-resistant hash functions). In order to be referenced by browser vendors (Opera comes to mind, and I think Mozilla will require this), the serial number MUST be random (or at least *appear* random from the outside). -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: How to disable index and serial?
Hodie pr. Id. Ian. MMXI, Mark H. Wood scripsit: > On Tue, Jan 11, 2011 at 07:23:54PM +0100, Erwann ABALEA wrote: > > In order to be referenced by browser vendors (Opera comes to mind, and > > I think Mozilla will require this), the serial number MUST be random > > (or at least *appear* random from the outside). > > Oh, now I'm curious. How do they test the randomness of a single > sample? "1" is every bit as random (or nonrandom) as > "0xdcb4a459f014617692d112f0942c89cb". That's not how it's done. When you apply for your Root CA to be referenced in a product, you supply your CP and CPS, and audit results. That's the auditor's job to ask how the serial is generated, in order to check that you really do what you say you do. Lying during the audit is of course technically possible, but it will surely be discovered one day, and you'll lose your business. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Possibility to create CRL without the CA key
Hodie IV Non. Mai. MMXI, Viliam Ďurina scripsit: > Thanks very much for the hints. Finally, I decided to generate CRL for three > years and replace it, when something needs to be revoked, if ever. I think > the support is not good. We will have to distribute the CRL issuer > certificate to partner applications to be able to verify the CRL signature. > And generally, the support and knowledge about indirect crl is low among > developers... That could lead to a problem with crypto toolkits that try to fetch a new CRL only when the actual has expired (it was a common behaviour some years ago, I don't know how this evolved). You could also pre-generate several CRLs, with a 1 month validity period, and "disclose" a new one regularly. -- Erwann ABALEA Département R&D KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com - Mammifère : se dit d'un animal à squelette, poilu, qui donne du lait. Exemple : une noix de coco. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] CA
Bonjour, Hodie XV Kal. Iun. MMXI, Jean-Ann GUEGAN scripsit: >Hi ! > >It’s possible to renew a Certificate Autority or extend the date validity >? These 2 options are possible. "Recertify" (i.e. sign the same certificate, but change the serial number and validity dates) is the least problematic solution, as the same public key will be used to validate the certificates and CRLs. "Renew" (i.e. create a entirely new certificate, strictly keeping the same exact subject DN, changing the key, validity dates, and potentially the extensions) is covered by the X.509 standard (a CA is a name, not a certificate). Sadly, you can't be sure it's correctly dealt with by verifiers. The new objects (certificates and CRLs) will be signed by the new CA key, the CRLs will cover both "old" and "new" certificates (by old, I mean those signed by the old CA certificate). If your CA is a root, and you want RFC5280 compliance, you MUST produce one CRL for each root CA certificate (and adapt the crlDistributionPoints). -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] CA
Hodie XV Kal. Iun. MMXI, Alex Bergmann scripsit: > On 05/18/2011 11:17 AM, Erwann ABALEA wrote: > >Bonjour, > > > >Hodie XV Kal. Iun. MMXI, Jean-Ann GUEGAN scripsit: > >>Hi ! > >> > >>It’s possible to renew a Certificate Autority or extend the date > >> validity > >>? > > > >These 2 options are possible. > > > >"Recertify" (i.e. sign the same certificate, but change the serial > >number and validity dates) is the least problematic solution, as the > >same public key will be used to validate the certificates and CRLs. > > > >"Renew" (i.e. create a entirely new certificate, strictly keeping the > >same exact subject DN, changing the key, validity dates, and > >potentially the extensions) is covered by the X.509 standard (a CA is > >a name, not a certificate). Sadly, you can't be sure it's correctly > >dealt with by verifiers. The new objects (certificates and CRLs) will > >be signed by the new CA key, the CRLs will cover both "old" and "new" > >certificates (by old, I mean those signed by the old CA certificate). > >If your CA is a root, and you want RFC5280 compliance, you MUST > >produce one CRL for each root CA certificate (and adapt the > >crlDistributionPoints). > > There seems to be a problem with this if you have AKID and SKID in > place. Certificates signed with the "old" Root Certificate will be > bound to the "old" Root Certificate serial number. You can verify > this with the output of "openssl x509" at the "X509v3 extensions" > section. "old" end-user certificates can only be verified by the "old" CA certificate, of course (in case the CA is "renewed", with its key changed, etc). > The only way I found was to give the new Root Certificate the same > serial number as the previous one. That's forbidden by X.509 standard. And the serial number has nothing to do with the SKI/AKI. > openssl req -new -x509 -days 1000 -key cakey.pem \ > -set_serial -out new_cacert.pem > > After that, verification of already signed certificates is working > fine with the old and new Root Certificate. Did you change the private key of the CA? If not, then: - the SKI of the new CA certificate will be the same as the old certificate (it's a *Key* identifier, and is generally constructed from the public key) - you don't need to have the same serial number (remember, it's forbidden by X.509 standard) - you will be able to verify old end-user certificates with the new CA certificate (since the CA key didn't change), if the rest of the CA certificate permits it (validity dates, extensions). If you were in this situation, and only were able to verify end-user certificates if the new CA certificate had the same serial number as the old one, then I'm sure you made a mistake in your tests. -- Erwann ABALEA Département R&D KEYNECTIS - Press Control-Alt-$ to appease spirits. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
Bonjour, Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit: > I do apologise - it's a long post. I'm just not totally sure if I > have the correct attributes and extensions - and whether it meets > the requirements of a v3 SSL cert (I think it does). Is 4096 bit key > and sha1 a good choice? SHA1 is still tolerated, but being slowly obsolete. You can still use it if your serial numbers have some randomness, which is not the case here. Either use one member of the SHA2 family, or generate random serial numbers. > And is the revocation bit done correctly (assuming I actually > maintain a CRL from openssl ca -gencrl at the url above? All the "ns*" extensions are deprecated, and shouldn't be used anymore. The nsCaRevocationUrl extension should be replaced by this: crlDistributionPoints = URI:http://www.example.com/ssl/CA-example.com.crl You don't need to place a CRLDP extension in the root CA certificate (a root can't really revoke itself). You forgot to place the keyUsage extension in your server certificates. The issuerAltName extension is useless as stated (I'd say it's also useless in general, but I won't argue). I'd set the critical flag for the basicConstraints extension (both CA and end-users (server+user)). -- Erwann ABALEA Département R&D KEYNECTIS - Your mouse has moved. Please reboot to continue. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
Bonjour Tim, Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit: > On 19/05/11 13:03, Erwann ABALEA wrote: [...] > >SHA1 is still tolerated, but being slowly obsolete. You can still use > >it if your serial numbers have some randomness, which is not the case > >here. Either use one member of the SHA2 family, or generate random > >serial numbers. > > Hi Erwann, > > Thanks for that. I'm not sure how to do random serials (I let > openssl manage those) but it interesting to know it makes a > difference. This how I do this: - in the setup phase, after having generated the CA private key, generate a secret key (16 random bytes taken from /dev/urandom will suffice), and place this key into /private/secretkey; I also create a file named "counter", in the same directory as the "serial" one, and init it with an "echo 1 > /counter" - when I want to sign a certificate, do this: SECRETKEY=`od -t x1 -A n DIRECTORY/private/secretkey | sed 's/ //g' | tr 'a-f' 'A-F'` COUNTER=`cat DIRECTORY/counter` echo `expr $COUNTER + 1` > DIRECTORY/counter SERIALHEX=`echo -n $COUNTER | openssl enc -e -K $SECRETKEY -iv -aes-128-cbc | od -t x1 -A n | sed 's/ //g' | tr 'a-f' 'A-F'` SERIAL=`(echo ibase=16; echo $SERIALHEX) | bc -l` and then either: - use "-set_serial $SERIAL" if you produce a self-signed certificate with the "openssl req" command - do "echo $SERIAL > DIRECTORY/serial", and run the "openssl ca" command as usual That way, the serial number is random for the outside, is guaranted to be unique, and stays deterministic for you (decrypt it with your secret key, and you'll be able to know which "number" it is, if you need). Using random serial numbers is interesting if the hash function is no more collision resistant (MD5 isn't, SHA1 is still up, but not for so long). [...] > >The nsCaRevocationUrl extension should be replaced by this: > >crlDistributionPoints = URI:http://www.example.com/ssl/CA-example.com.crl > > OK - cool. Should I support both do you think for backwards compatibility? Just use crlDistributionPoints, everybody wanting to download a CRL will do this from this extension. This "ns" (netscape) extension is of no use. > >The issuerAltName extension is useless as stated (I'd say it's also > >useless in general, but I won't argue). > > What should it be in this context? Don't use this extension, unless you want to name your CA with another name as the one given in its issuerName :) [...] > This is one of those jobs that I assign the "want to do it right" > flag too - I have a 100 servers that eventually need new certs > (though I will probably be forced to use a wildcard CN on most of > them as many do name based virtual hosting on apache - yes I know, > the RFCs only mention wildcard CNs in the context of a few services > and not specifically HTTPS, but what can you do...) > > Cheers, > > Tim > > I read an interesting blog by a google employee on the issue of CRLs > and avoiding the whole issue by setting up automatic distribution of > very short time-to-live certs: > > http://www.imperialviolet.org/2011/03/18/revocation.html > > (Adam is an ex-student of the uni I used to work at - a very sharp > fellow indeed). That's an interesting point. The author could have given more detailed information, as some browsers use the native OS crypto API (for example IE, Chrome or Safari), or use NSS when nothing is provided by the OS (Chrome on Linux), or use their own crypto API (NSS for Firefox, something else for Opera). The revocation validation is generally performed by the used crypto API. To simplify it a little more, EV behaviour is not imposed by this API, and is proprietary to the browser. You can surely deliver short-lived certificates, but you'll have to renew them more often, and deploy them, etc. That's a lot of work :) This solution has also be mentioned in the Mozilla CA Policy group. -- Erwann ABALEA Département R&D KEYNECTIS - If at first you don't succeed; Blame everyone else __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
Bonjour Tim, Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit: > On 19/05/11 14:48, Erwann ABALEA wrote: > >Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit: > > >>Thanks for that. I'm not sure how to do random serials (I let > >>openssl manage those) but it interesting to know it makes a > >>difference. > > > >This how I do this: > > - in the setup phase, after having generated the CA private key, > >generate a secret key (16 random bytes taken from /dev/urandom will > >suffice), and place this key into/private/secretkey; I also > >create a file named "counter", in the same directory as the > >"serial" one, and init it with an "echo 1> /counter" > > - when I want to sign a certificate, do this: > > SECRETKEY=`od -t x1 -A n DIRECTORY/private/secretkey | sed 's/ //g' | > > tr 'a-f' 'A-F'` > > COUNTER=`cat DIRECTORY/counter` > > echo `expr $COUNTER + 1`> DIRECTORY/counter > > SERIALHEX=`echo -n $COUNTER | openssl enc -e -K $SECRETKEY -iv > > -aes-128-cbc | od -t x1 -A n | sed 's/ > > //g' | tr 'a-f' 'A-F'` > > SERIAL=`(echo ibase=16; echo $SERIALHEX) | bc -l` > >and then either: > > - use "-set_serial $SERIAL" if you produce a self-signed > > certificate with the "openssl req" command > > - do "echo $SERIAL> DIRECTORY/serial", and run the "openssl ca" > > command as usual > > I presume there is a slight possibility of a serial number clash > with that? Not that it's a problem, but it would be wise to check > index.txt to see if the number has been used before? Really, no. A counter is encrypted, and the result of the encryption is the serial number. If you imagine a collision in this serial number generation scheme, then it means that a ciphertext (serial number) can be decrypted into 2 different plaintexts (counter). That's impossible if the secret key is constant. The problem with this scheme is that it doesn't deal well with parallel certificate signatures. You have one shared information that must be incremented in an atomic way. But for a "Junk CA" (that's how I call the set of scripts I use), that's not a problem. You could have used another scheme: - generate 16 random bytes - place them in the serialNumber With such a scheme, yes, a collision could occur, and you should check the index.txt file first. Beware of the "ca" command line tool if you have a large population. I wanted to use it for a massive certificate generation (in order to fill an LDAP directory), and the time taken to generate a certificate goes larger with the number of generated certificates (it must load the file into memory, check if the given name either doesn't exist or exists only with revoked or expired certificates, extend the list, and finally write it again onto disk). [...] > >You can surely deliver short-lived certificates, but you'll have to > >renew them more often, and deploy them, etc. That's a lot of work :) > >This solution has also be mentioned in the Mozilla CA Policy group. > > I have a masterplan for that :) I have, out of necessity, a very > secure "gold server" that has access to everything else (it will > become the master Kerberos server one day and also needs to auto > distribute kerberos keys when that happens). It is extremely well > protected - which means the issue of caching the CA passphrase on it > is moot (if anyone hacks that server, they own everything anyway - > SSL will be the least of our problems - a point that is generally > true of any master authentication or config management server even > without the additional abilities this one has). > > The infrastructure I envisage is one where a database will have a > record of all SSL enabled services and cert/key file locations plus > CN information - which makes it practical to run and distribute by > itself - which then makes Adam's idea viable. Then this deployment server will be your SPOF :) -- Erwann ABALEA Département R&D KEYNECTIS - ``It's nice to be important, but it's important to be nice.'' Anon. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit: > On 19/05/11 16:46, Peter Sylvester wrote: > >another approach is to take the value of 'time' (the current second) > >and append to it the current process number, and, in case of > >several machines, some number indicating the id of the machine. > > > >instead of the process number, any other method to ensure uniqueness > >within a second may be used. > > Ah yes - that would guarantee a non repeating unpredictable sequence. > > I was confuse initially as I did not realise the serial number could > be so big (16 bytes was it?). 20 bytes max, for the RFC5280. -- Erwann ABALEA Département R&D KEYNECTIS - If you never try anything new, you'll miss out on many of life's great disappointments. Demotivators, 2002 calendar __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] CA
Hodie XIV Kal. Iun. MMXI, Dave Thompson scripsit: > > From: owner-openssl-us...@openssl.org On Behalf Of Erwann ABALEA > > Sent: Thursday, 19 May, 2011 04:20 > > > Hodie XV Kal. Iun. MMXI, Alex Bergmann scripsit: > > > > The only way I found was to give the new Root Certificate the same > > > serial number as the previous one. > > > > That's forbidden by X.509 standard. And the serial number has nothing > > to do with the SKI/AKI. > > > There are (at least) two kinds of AuthorityKeyIdentifier. > > AKI=SKI identifies only the parent (CA) key (by hash), > and is ambiguous if CA gets new cert for same key. > > AKI=issuerSerial *does* use parent (CA) serial. You're right, the AKI extension can be populated with these 2 informations (in fact, really 3, but 2 of them are linked together in the X.509, and not in RFC5280). -- Erwann ABALEA Département R&D KEYNECTIS - ``Do or do not. There is no try." Yoda __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] cipher suite ECDH-ECDSA-AES128-SHA256
Bonjour, Hodie VIII Kal. Iun. MMXI, shoutee scripsit: > I want to run a TLS Server with support of cipher suite > 'ECDH-ECDSA-AES128-SHA256' (RFC 5289). Unfortunately I can't find these > cipher suite > within tls1.h. ECDSA is only available with SHA1. > > Since openssl supports SHA256 I thought that ECDSA with SHA256 should be > available, or am I missing something? > I'm using openssl-1.0.0d. The ciphersuites defined in RFC5289 apply to TLS1.2 only. OpenSSL doesn't support (yet) TLS1.2. If your next question is "when will OpenSSL support TLS1.2?", you'll find the answer in the archives, as it has been asked quite some times. -- Erwann ABALEA Département R&D KEYNECTIS - Architect: Someone who knows the difference between that which could be done and that which should be done. Larry McVoy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] cipher suite ECDH-ECDSA-AES128-SHA256
Bonjour, Hodie VIII Kal. Iun. MMXI, Dr. Stephen Henson scripsit: > On Wed, May 25, 2011, Erwann ABALEA wrote: > > Hodie VIII Kal. Iun. MMXI, shoutee scripsit: > > > I want to run a TLS Server with support of cipher suite > > > 'ECDH-ECDSA-AES128-SHA256' (RFC 5289). Unfortunately I can't find these > > > cipher suite > > > within tls1.h. ECDSA is only available with SHA1. > > > > > > Since openssl supports SHA256 I thought that ECDSA with SHA256 should be > > > available, or am I missing something? > > > I'm using openssl-1.0.0d. > > > > The ciphersuites defined in RFC5289 apply to TLS1.2 only. OpenSSL > > doesn't support (yet) TLS1.2. > > If your next question is "when will OpenSSL support TLS1.2?", you'll > > find the answer in the archives, as it has been asked quite some > > times. > > The answer however has changed: experimental TLS v1.2 code is present in HEAD > and the 1.0.1 stable branch. The code hasn't been fully tested yet so some I forgot that, it was mentioned once recently, you're right. Was that work funded, or did some developer dedicate some spare time for this? > If anyone knows of any public servers supporting TLS v1.2 I'd be interested > in some interop testing. If you can install a recent IIS, you'll have TLS1.2. Recent versions of GNUTLS also support TLS1.2. IE9 (probably on Windows 7) also supports TLS1.2, if you want to test the server part. -- Erwann ABALEA Département R&D KEYNECTIS - Stupidity has no limits, genius does. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] OCSP request / response over HTTP-GET
Hodie V Kal. Iul. MMXI, Sugimoto, Koichi - GlobalSign K.K. scripsit: > It seems that OpenSSL does not compliant to RFC 5019. > Are there anyone prepareing to develop HTTP-GET based OCSP command? > As for server, malformedRequest (1) is returned if received HTTP-GET based > ocsp request. RFC5019 is "The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments". OpenSSL as a command-line tool can't be used in a "high volume environment" (in fact, it quits when it receives anything else than "POST" as a verb). If you have such needs, then you're able to write your own, using OpenSSL API. -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: revoking crt
Hodie XIV Kal. Aug. MMXI, y...@inbox.lv scripsit: >If that CRL is trying to revoke that root certificate, what in that CRL >could ber forged? If that CRL tells the private key is compromised, how could you trust this CRL (since it was signed by a compromised private key)? >CRL can only revoke a CRT, not unrevoke, right? Yes, it can. A CRL is a "present state" of revoked certificates. Remove a certificate's serial number from a CRL, it is no longer revoked. A root CA can not be revoked, that's all. Think of revocation as an automatic way to suspend trust in a certificate. PKI only transfers trust, it doesn't create it. The trust that is transferred (by signing and/or revoking certificates) is explicitely (and manually) placed into the root, by an off-band method. Revocation of the root would consist of removal of this trust, and as it was manually added, it also must be manually removed. >I know, that when revoking a certificate, CRL is signed by certificate >issuer (CA), >is there a reason, why a (small) CRL could not be signed by cartificate >itself? CRL scope. Read X.509. >(after all, anyone using leaked private key would be intereseted to delay >revocation, > but they have no means of preventing it) -- Erwann ABALEA Département R&D KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com - All wiyht. Rho sritched mg kegtops awound? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How to do a PKCS#10 in embedded systems
Hodie pr. Non. Aug. MMXI, Giordano Bruno scripsit: > Hi people, I have a problem in in certifications in low level issue, > but I think it is the best place to solve, > > I need to generate a PKCS#10 with a very limited device, a MSP430F5438 > from Texas Instruments plus a co-processor that implement the RSA and > SHA-1 algorithms. > > The coprocessor generate the key pair, as shown below. I used the > private key generate to sign the part in the of the CSR message. I > used RSA 1024 with SHA-1 algorithms to do this. As result we got the > file example.der. I used the site > <http://www.motobit.com/util/base64-decoder-encoder.asp> to transform > the DER file in the example.pem. To validate this information, I use > the site <http://www.redkestrel.co.uk/cgi/decodeCSR.cgi>, achieving as > result the warning "The CSR has an invalid signature". The signature is really invalid. I took your DER file, extracted the signature block on one side, extracted the public key on the other side, and performed the raw RSA verification operation: openssl rsautl -in example.der.sig -inkey example.key -pubin -verify -hexdump -raw - 32 dc d5 61 c5 88 4a 00-b3 a9 9b c2 61 ce d6 01 2..a..J.a... 0010 - f6 b4 83 9b 60 0f 7d 99-15 34 e6 47 98 2b 06 5a `.}..4.G.+.Z 0020 - cc 07 39 c6 f7 87 f4 75-6e 1a 16 5b 32 70 5a a3 ..9un..[2pZ. 0030 - 5e 42 c0 71 02 4c a3 1d-48 31 7c 7c 12 bb 3f e6 ^B.q.L..H1||..?. 0040 - c4 4d e7 dc 43 80 0e b8-fe cb ba 15 b6 1e 8c 3d .M..C..= 0050 - 1b 98 31 04 23 51 9d 26-d7 ac fc a5 6d 47 6a 4f ..1.#Q.&mGjO 0060 - 9d bb 12 e3 e0 44 c7 4d-23 4c c0 49 a6 40 fe 38 .D.M#L.I.@.8 0070 - e7 ab 48 f6 a3 f3 a5 a6-1a 11 bb 1b 94 d9 e0 bc ..H. This isn't a valid signature (02, padding, DER sequence with hash OID and value). Are you sure of your public key? -- Erwann ABALEA Département R&D KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How to do a PKCS#10 in embedded systems
Bonjour,
Hodie pr. Non. Aug. MMXI, Giordano Bruno scripsit:
> Thank you for reply,
> I didn't understand what you mean with this sequence (02, padding, DER
> sequence with hash OID and value). Can you explain?
> The hash of our der file (without the first header, the signature
> header and the signature) should be the expected result of your
> command (openssl rsautl -in example.der.sig -inkey example.key -pubin
> -verify -hexdump -raw)?
The command I used displays the integer that has been signed in the
RSA process. So yes, the hash of your data should have been embedded
in this result, encapsulated in a structure.
I made a mistake, it doesn't start with 02, but with 00 01. Here's an
example of a valid "before signature block", signed by a 2048bits RSA
key, with the sha1withRSA signature scheme (I got this with the same
command, obviously on other data):
00 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff 00 30 21 30
09 06 05 2b 0e 03 02 1a 05 00 04 14 80 08 3f d2
05 06 6b e1 0a f3 75 39 70 d2 5b 57 01 37 2c df
Everything is described by the PKCS#1 standard, and the text is freely
available. You should be able to recognize the following structure:
30 21 SEQUENCE {
30 09 SEQUENCE {
06 05 2b 0e 03 01 1a OID (sha1)
05 00 NULL
}
04 14 ... 2c df OCTET STRING (the hash value)
}
Download and read PKCS#1, and you'll have a better understanding.
--
Erwann ABALEA
Département R&D
KEYNECTIS
11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France
Tél.: +33 1 55 64 22 07
http://www.keynectis.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] How to do a PKCS#10 in embedded systems
Bonjour Giordano Hodie Non. Aug. MMXI, Giordano Bruno scripsit: > I tried your command, but I got an error: > > C:\OpenSSL-Win32\bin>openssl rsautl -in example.der.sig -inkey > example.key -pubin -verify -hexdump –raw > Loading 'screen' into random state - done > unable to load Public Key You first have to create the necessary files, extracted from the request (since it is self-signed). > I read the PKCS#1, PKCS#8, PKCS#7 and PKCS#10 and now I have an better > idea from PKI, but I'm still a begginer in these contents. > > Could you tell-me how to make the example.key and example.der.sig? Is > it in Base64 encoding? Let's start with your example file: example.der. Extract the contained public key: openssl req -pubkey -inform D -in example.der -noout > example.key Now we'll extract the signature block. Start by ASN1-parse your file: openssl asn1parse -inform D -i -dump -in example.der You'll see the subject name, public key, extension requests, and the signature at the end: 318:d=1 hl=3 l= 129 prim: BIT STRING - 00 8f 2c 23 95 d5 70 b6-19 df 20 fb 59 a6 e8 9f ..,#..p... .Y... 0010 - 5d 59 0b b5 33 69 6b ee-8b 4f 4e f8 1a 4d be 12 ]Y..3ik..ON..M.. 0020 - 30 5b 8b 1c bf 3b 09 9b-62 9c 00 a9 47 91 0d 06 0[...;..b...G... 0030 - a4 3f 6e e7 a4 77 32 f4-ca 09 c7 1a b2 2f e8 62 .?n..w2../.b 0040 - c7 43 b1 0e a4 fe d6 61-fa 6c 43 81 3e af de a9 .C.a.lC.>... 0050 - 79 2d 72 b5 3a bc 00 01-59 d3 86 59 45 7a 28 54 y-r.:...Y..YEz(T 0060 - 55 c6 b7 45 c0 22 96 6c-7a b1 a3 b7 f5 3f e2 5f U..E.".lz?._ 0070 - c9 96 b0 b8 2c 3c dc b8-9b 0b c0 e5 77 41 5a ae ,<..wAZ. 0080 - 61a You know that the signature starts at offset 318. We need only the raw signature, so we'll skip the first 318 bytes, the header (hl=3, so skip 3 more bytes), and since it's a bit string, it starts with the number of unused bits (expressed in one octet, 00 in this case), you must also skip this octet. Finally, you need to skip 318+3+1=322 bytes: dd if=example.der of=example.der.sig bs=1 skip=322 The command should tell you that it has extracted 128 bytes, which is the size of your 1024bits RSA signature. Since you're working under Windows, you'll need to find a dd binary, or do the operation on a Unix-like machine. Now, you can perform the raw RSA verification: openssl rsautl -in example.der.sig -inkey example.key -pubin -verify -raw -hexdump And you'll get the data that was passed to your signature function: - 32 dc d5 61 c5 88 4a 00-b3 a9 9b c2 61 ce d6 01 2..a..J.a... 0010 - f6 b4 83 9b 60 0f 7d 99-15 34 e6 47 98 2b 06 5a `.}..4.G.+.Z 0020 - cc 07 39 c6 f7 87 f4 75-6e 1a 16 5b 32 70 5a a3 ..9un..[2pZ. 0030 - 5e 42 c0 71 02 4c a3 1d-48 31 7c 7c 12 bb 3f e6 ^B.q.L..H1||..?. 0040 - c4 4d e7 dc 43 80 0e b8-fe cb ba 15 b6 1e 8c 3d .M..C..= 0050 - 1b 98 31 04 23 51 9d 26-d7 ac fc a5 6d 47 6a 4f ..1.#Q.&mGjO 0060 - 9d bb 12 e3 e0 44 c7 4d-23 4c c0 49 a6 40 fe 38 .D.M#L.I.@.8 0070 - e7 ab 48 f6 a3 f3 a5 a6-1a 11 bb 1b 94 d9 e0 bc ..H. You then can manually verify the padding, hash algo, hash value, etc. -- Erwann ABALEA Département R&D KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Wget can't validate some certificates.
Hodie VII Id. Aug. MMXI, Kamil Jońca scripsit: > I have weird problem with some sites using ssl. > Mozilla _can_ validate certificate but wget can't, and I don't know if > it is a debian bug or openssl. > Whole story begins at > http://lists.debian.org/debian-user/2011/06/msg00089.html The certificate chain sent by the website is this: 0. s:/1.3.6.1.4.1.311.60.2.1.3=PL/2.5.4.15=Private Organization/serialNumber=008723/C=PL/postalCode=50-950/ST=Dolnoslaskie/L=Wroclaw/streetAddress=ul. Rynek 9/11/O=Bank Zachodni WBK S.A./OU=Obszar Operacji Bankowych/CN=www.centrum24.pl i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA issuer hash bae2cbd8/ac12bd91 1. s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 subject hash bae2cbd8/ac12bd91 issuer hash facacbc6/b204d74a 2. s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority subject hash facacbc6/b204d74a issuer hash 7651b327/415660c1 Your wget binary wants to validate the certificate sent in position 2, which is signed by a previous VeriSign Root CA. So it looks for a file or link named 415660c1.0 in the /usr/lib/ssl/certs/ directory, and can't find it. Are you sure it doesn't look for a file or link named b204d74a.0 in the same directory, after that? Normally, it should try to validate the position 1 certificate with its certificate store. -- Erwann ABALEA Département R&D KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] loadbalancer affinity/persistence with tls sessiontickets
Bonjour, Hodie VIII Kal. Sep. MMXI, Arjan Filius scripsit: > Does one know it the tls sessionticket consept could work with > loadbalancer afinity/persistence? It is perfectly suited to dumb loadbalancers. The session state is the ticket, and is saved by the client, encrypted by the server's private key. -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: users auth. in XP for HTTPS
Hodie III Kal. Sep. MMXI, Jakob Bohm scripsit: > On 8/30/2011 3:29 AM, Dave Thompson wrote: > >... > >That sounds like the keyUsage bit dataEncipherment, and OpenSSL CA > >can set it. But SSL never *does* dataEncipherment using a > >certificate/key, so this bit should not be needed or make any > >difference. > Small correction: SSL/TLS never does dataEncipherment with *client* > certificates, and always does dataEncipherment with *server* > certificates (if any). Correction to the correction: TLS always does dataEncipherment with server certificate *if* the key exchange algorithm is RSA. > So dataEncipherment should be set in the SSL server certificate and > clear in the SSL client certificate, as is apparently already the case > here, so that part is OK. Even if you don't set the dataEncipherment bit in the keyUsage extension, it works. TLS libraries are tolerant :) -- Erwann ABALEA Département R&D KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com - It works better if you plug it in where it should be. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] openssl.org web site certificate renewed
Bonjour, Hodie III Kal. Sep. MMXI, Lutz Jaenicke scripsit: > I have just installed a new 3 year wildcard "*.openssl.org" certificate > to our web site. > Thanks to GlobalSign for the new donation. > > The migration should work more or less unnoted for the users. If you > experience any problems please drop me a message. Thanks to them, yes. Maybe you could remove the root CA from file designed by the SSLCertificateChainFile directive? It's useless to send it to the client, as you know, and you may gain 1 TCP packet (+ ACK in return) during the negotiation. You should also disable SSLv2, and <128bits ciphers. -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: [openssl-dev] openssl.org web site certificate renewed
Bonjour,
Hodie III Kal. Sep. MMXI, Jakob Bohm scripsit:
[...]
> 1) The CA has changed/improved the attributes, e.g. by extending the
> expiry date or adding a CRL
> location for detecting future root cert revocation (a good
> precaution for CA's to take, coupled with
> a pre-generated key compromise CRL stored somewhere off-site but secure).
The relying party won't automatically update its trust store when
receiving such a certificate, even if the key is reused. So it won't
trust this new certificate, and won't use it to build a valid
certification path. But you can of course manually grab it for this:
> 2) My browser lacks the CA cert, in which case having it at hand
> eliminates one of the two steps
> in securely adding it (the other step is to compare the cert hash
> ("fingerprint") with a known published
> value).
Is that really useful? Always sending a useless certificate in case
someone would need it and use "openssl s_client -connect ...
-showcerts" to update its database, instead of providing a link to
this certificate somewhere?
--
Erwann ABALEA
Département R&D
KEYNECTIS
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] View OCSP response in CMS
Le 21/09/2011 21:20, Gabriel Marques a écrit : I'm developing a tool for signing digital TV apps, and one of the goals was to embed OCSP responses into the CMS signature file of the application. The idea is that the broadcaster equipment would query the OCSP and update the response with certain frequency, so that the receiver could check the certificate validity without Internet connection. Well, using the BouncyCastle lib I've forcedly embedded the response in the OtherRevocationInfoFormat field of the CMS file, but OpenSSL does not like the way I did it: -> openssl cms -cmsout -print -inform der -in /tmp/sig3/META-INF/BR-ecdsaTest.EC Error reading S/MIME message 3076389608:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1319: 3076389608:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:381:Type=X509_CRL_INFO 3076389608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:751:Field=crl, Type=X509_CRL 3076389608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:751: 3076389608:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:339:Field=d.crl, Type=CMS_RevocationInfoChoice This could be because I'm doing something wrong (probably) or because OpenSSL (1.0e) is alway expecting a CRL set where other kind of revocation info could be present. I couldn't find a clear way to do insert OCSP responses into a CMS structure. The RFCs are the clearer source I could get: RFC 3852 - CMS structure: The latest RFC for CMS is 5652. But the phrasing is the same: - IF ((certificates is present) AND (any certificates with a type of other are present)) OR ((crls is present) AND (any crls with a type of other are present)) THEN version MUST be 5 ELSE [...] - In your examples, you set version to 3. Based on your parsed example, it seems you correctly set the tag ([1]) for the "crls" element, but you didn't use the good encoding for the "other" field (of type "OtherRevocationInfoFormat", as it also must be tagged ([1]) and be identified by the correct OID (1.3.6.1.5.5.7.16.2). -- Erwann ABALEA - Le neuneu est un con qui débute. C'est une espèce rare mais qui fait beaucoup de bruit. -+- JCD in : Guide du Neuneu d'Usenet -- Bien configurer son neuneu.-+-
Re: [openssl-users] openssl and rfc 5280
Le 22/09/2011 16:10, Roger No-Spam a écrit : Hi, I'm trying to understand if openssl is a good base when implementing a system that is to be compliant with rfc 5280. Are there any limitations or missing parts in openssl? Using OpenSSL, you can implement a system mostly compliant with RFC5280. You will have to enforce some constraints by yourself, for example: - check that the serial number of a certificate is positive and no longer than 20 octets - check the AVA lengths (64 for a CN, O, OU, ...) - check that the basicConstraints extension for a CA is present and critical, with its CA flag set - check that the certification path of a verified certificate and the certification path of the CRL used to check its revocation status meet to the very same trustpoint (key) - ... probably some others The fact is OpenSSL is not "pure RFC5280", it's a toolkit you can use for pretty much anything regarding PKI (X.509 and others), crypto, SSL, ... RFC5280 is a profile of X.509, i.e. X.509 with constraints. -- Erwann ABALEA - apaléostéoplasique: qui ne fait pas de vieux os
Re: [openssl-users] View OCSP response in CMS
Le 22/09/2011 16:10, Dr. Stephen Henson a écrit : On Thu, Sep 22, 2011, Erwann Abalea wrote: [...] In your examples, you set version to 3. Based on your parsed example, it seems you correctly set the tag ([1]) for the "crls" element, but you didn't use the good encoding for the "other" field (of type "OtherRevocationInfoFormat", as it also must be tagged ([1]) and be identified by the correct OID (1.3.6.1.5.5.7.16.2). That agrees with my analysis. OpenSSL is choking on that field because it is expecting a CRL. Exactly. You seem to be fluent in OpenSSL ;) Note that OpenSSL doesn't enfornce the version value in the parser. "Strict on emitting, relax on receiving"-motto. But not relax enough to be able to recognize an OCSP token in a CertificateList. Shame. (just kidding, not cafeinated enough) -- Erwann ABALEA - Bien reçu message via groupes discussion, je te répond avec la touche " répondre au groupe " en ayant sélectionné ton message. J'espère que tu le recevra dans ta boîte de réception. Le café est en préparation. -+- in Guide du Neuneu Usenet - Open up, open up -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Revocation with a renewed/rekeyed Root CA
Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) Given CA1g1 and CRLg1 in the "CApath", I can validate U2 and U3, and U1 is correctly declared revoked. I now renew CA1, with a rekey. I now have a second generation of the same CA (same name), lets call it CA1g2. CA1g2 issues U4, U5, U6. Given a "CApath" containing CA1g1, CA1g2, and CRLg1, I can still validate U2 and U3, and check that U1 is revoked. However, I cannot check U4 to U6, OpenSSL complains that it cannot find the CRL (I used strace to check that it reads the CRL "xxx.r0", and tries to find another one "xxx.r1"). If I generate a new CRL with CA1g2 (named CRLg2), and replace CRLg1 with CRLg2 in the "CApath", I cannot validate U1 to U3 (same result: cannot find CRL), but I can validate U4 to U6. It seems OpenSSL follows the RFC5280 rule added during the transition from RFC3280 to RFC5280, which says "the trust anchor for the certification path MUST be the same as the trust anchor used to validate the target certificate" (6.3.3, f). However, this constraint is only local to RFC5280, it didn't exist before, and does not exist in X.509. Read paragraph 8.1.5 of the 2008 edition of X.509: - If an authority uses the same key to sign certificates and CRLs, a single self-issued certificate of category a) shall be used. If an authority uses a different key to sign CRLs than that used to sign certificates, the authority may choose to issue two self-issued certificates of category a), one for each of the keys. In this situation, certificate users would need access to both self-issued certificates to establish separate trust anchors for certificates and CRLs signed by that authority. - category a) is a self-signed certificate, issued "as a convenient way of encoding the public key associated with the private key used to sign the certificate, so that it can be communicated to, and stored as trust anchors by, its certificate using systems". I looked at the test descriptions of the NIST's PKITS, the renewal of the root is not taken into consideration, no help from them. So, while the PKIX IETF point of view is now clearly: "you never renew the whole hierarchy, you just create a new one in parallel, which can eventually have the same name", it contradicts X.509 (a CA is a name). Shouldn't OpenSSL give a way to follow X.509 rather that RFC5280? Have I missed a specific option that does just that? -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: Revocation with a renewed/rekeyed Root CA
Le 17/10/2011 14:34, Eisenacher, Patrick a écrit : Hi Erwann, -Original Message- From: Erwann Abalea Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) you can't revoke a root CA by the means of a CRL. This works only out-of-band, i.e. you have to declare that the root CA in question is revoked and spread the news to all your customers. I know that I can't revoke a root, and I didn't try to do that. Maybe my phrasing wasn't clear enough? The problem here is that you can't trust a CRL when its signature key is compromised. The X.509 2008 edition category b) concept that you cite is new to me and according to my understanding of PKI this doesn't make sense, because there is no trust relationship between any self signed keys, so I can't trust that key 2 has any relationship to key 1, specially not to issue its CRLs. In fact, the same paragraph exists in the 2005 edition of X.509. This paragraph was shorter in the 2000 edition. The idea here is that a CA is a name, not a key. You have the same principle for intermediate CAs, i.e. when you renew an intermediate CA, the CRL produced by the new private key encloses all the certificates: the ones generated before the renewal as long as the ones generated after the renewal. -- Erwann ABALEA - j'ai entendu dire qu'une société allait commercialiser des logiciels permettant de ne pas télécharger les pubs et je vous trouvre cela inadmissible. Les sites seront mis tout nu et cela ridiculisera le site. -+- BL in: Guide du Neuneu d'Usenet - A poil, tout le monde a poil -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: Revocation with a renewed/rekeyed Root CA
Le 17/10/2011 16:09, Jakob Bohm a écrit : On 10/17/2011 3:47 PM, Erwann Abalea wrote: Le 17/10/2011 14:34, Eisenacher, Patrick a écrit : Hi Erwann, -Original Message- From: Erwann Abalea Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) you can't revoke a root CA by the means of a CRL. This works only out-of-band, i.e. you have to declare that the root CA in question is revoked and spread the news to all your customers. [OT note, please discuss in separate thread] I have seen CAs that declare an additional CRL for potentially revoking the CA itself. Yes, and that was supported by mod_ssl, even for non self-signed CAs, before the switch to OpenSSL CRL mechanism. That's not standard, of course. That CRL is initially empty, but might one day be replaced by one that revokes the (self-)issued CA cert, thus invalidating itself. A recipient of such a "suicide CRL" has two reasonable options: A) Accept it and revoke its own trust in that CA. B) Declare a logic error thus preventing use of that CA until the compromising entity issues a new empty CRL. I know that I can't revoke a root, and I didn't try to do that. Maybe my phrasing wasn't clear enough? The problem here is that you can't trust a CRL when its signature key is compromised. The X.509 2008 edition category b) concept that you cite is new to me and according to my understanding of PKI this doesn't make sense, because there is no trust relationship between any self signed keys, so I can't trust that key 2 has any relationship to key 1, specially not to issue its CRLs. In fact, the same paragraph exists in the 2005 edition of X.509. This paragraph was shorter in the 2000 edition. The idea here is that a CA is a name, not a key. You have the same principle for intermediate CAs, i.e. when you renew an intermediate CA, the CRL produced by the new private key encloses all the certificates: the ones generated before the renewal as long as the ones generated after the renewal. Just to clarify: Does the "renewed" CA have the same public/private key but different attributes/expiry or does it have different public/private key and different attributes/expiry? (I understand that they have the same distinguished name). As I said, I renewed and rekeyed it. So that's a new key pair, for the same CA (same name), and of course different validity dates. -- Erwann ABALEA - apyrolacustre: pouvant attendre __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Revocation with a renewed/rekeyed Root CA
I forgot to tell that I did these tests with version 1.0.0e. Le 17/10/2011 14:14, Erwann Abalea a écrit : Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) Given CA1g1 and CRLg1 in the "CApath", I can validate U2 and U3, and U1 is correctly declared revoked. I now renew CA1, with a rekey. I now have a second generation of the same CA (same name), lets call it CA1g2. CA1g2 issues U4, U5, U6. Given a "CApath" containing CA1g1, CA1g2, and CRLg1, I can still validate U2 and U3, and check that U1 is revoked. However, I cannot check U4 to U6, OpenSSL complains that it cannot find the CRL (I used strace to check that it reads the CRL "xxx.r0", and tries to find another one "xxx.r1"). If I generate a new CRL with CA1g2 (named CRLg2), and replace CRLg1 with CRLg2 in the "CApath", I cannot validate U1 to U3 (same result: cannot find CRL), but I can validate U4 to U6. It seems OpenSSL follows the RFC5280 rule added during the transition from RFC3280 to RFC5280, which says "the trust anchor for the certification path MUST be the same as the trust anchor used to validate the target certificate" (6.3.3, f). However, this constraint is only local to RFC5280, it didn't exist before, and does not exist in X.509. Read paragraph 8.1.5 of the 2008 edition of X.509: - If an authority uses the same key to sign certificates and CRLs, a single self-issued certificate of category a) shall be used. If an authority uses a different key to sign CRLs than that used to sign certificates, the authority may choose to issue two self-issued certificates of category a), one for each of the keys. In this situation, certificate users would need access to both self-issued certificates to establish separate trust anchors for certificates and CRLs signed by that authority. - category a) is a self-signed certificate, issued "as a convenient way of encoding the public key associated with the private key used to sign the certificate, so that it can be communicated to, and stored as trust anchors by, its certificate using systems". I looked at the test descriptions of the NIST's PKITS, the renewal of the root is not taken into consideration, no help from them. So, while the PKIX IETF point of view is now clearly: "you never renew the whole hierarchy, you just create a new one in parallel, which can eventually have the same name", it contradicts X.509 (a CA is a name). Shouldn't OpenSSL give a way to follow X.509 rather that RFC5280? Have I missed a specific option that does just that? -- Erwann ABALEA - DP> http://couic-couic.fr le lien ne marche pas... -+- W in: Guide du Neuneu d'Usenet - Je lui fais couic-couic -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: specifying certificate extensions on command line
No. You can generate your conf file based on other elements, if you need something more flexible. Le 07/12/2011 13:06, sandeep kiran p a écrit : Anyone? can I do this without the conf file? Thanks Sandeep On Thu, Dec 1, 2011 at 7:36 PM, sandeep kiran p mailto:sandeepkir...@gmail.com>> wrote: Hi, Is there any way to specify the certificate extensions (when using "req" and "ca" tools) directly on the command line rather than using the -extensions argument? I am looking for a way where I can avoid using the config file with the "req" and "ca" commands. Thanks, Sandeep -- Erwann ABALEA - pyropyge: qui a le feu aux fesses
Re: [openssl-users] Re: Special character in CA name
Have you tried this: openssl x509 -text -noout -in blablabla.pem -nameopt -esc_msb Le 14/12/2011 19:16, Vladimir Puz a e'crit : I have the same problem, but with KOI8-RU certificates. It will be great if someone can help. *On Wed, 14 Dec 2011 16:19:41 + (UTC), Lou Picciano wrote* > as I understand it, using the utf8 option should allow any characters you might want. > Let us know how you get on; I've had trouble with this, too... > > Lou Picciano > > *From: *"gkout" > *To: *openssl-users@openssl.org > *Sent: *Tuesday, December 13, 2011 5:35:27 PM > *Subject: *Special character in CA name > > Hello again, > > This time I have an issue with a special character in the CA name which is > converted by openssl. > ESPA\xC3\x91A which should read [UTF-8?]"ESPAц▒A" with an [UTF-8?]"ц▒". -- Erwann ABALEA - Comme je ne veux pas fournir mon n°CB par Internet (...) je n'ai pas pu tester le syste`me. Mais j'aimerais bien avoir l'avis de quelqu'un qui l'a essaye'. -+- N in : Guide du Neuneu Usenetien - Passez devant je vous suis -+-
Re: [openssl-users] Re: Special character in CA name
Do you have an UTF8 capable terminal? Can you send the certificate you're testing? Le 15/12/2011 09:17, gkout a écrit : No joy... openssl x509 -text -noout -in blablabla.pem -nameopt -esc_msb outputs : ESPA%D1A -- Erwann ABALEA - ypéritorhinotachytrope: colérique, qui s'énerve rapidement __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 15:07, Jakob Bohm a écrit : I think we may have a bug here, anyone from the core team wish to comment on this. The apparent bug: When enforcing the "match" policy for a DN part, openssl reports an error if the CSR has used a different string type for the field, but the correct value (The naively expected behavior is to realize the strings are identical and use the configured encoding for the resulting cert). Do you expect the "openssl ca" tool to apply the complete X.520 comparison rules before checking the policy? 3. Validating a certificate whose issuing CA certificate specifies path constraints where the issued certificate satisfies the path constraint except for the exact choice of string type. NameConstraints is a set of constraints imposed on the semantic value of the name elements, not on their encoding (string type, double-spacing, case differences, etc). Technical note: All the defined string types have a well defined mapping to and from 32 bit Unicode code points, with the following one-way limitations: BMPStrings can only represent U+ to U+10 (using UTF-16) UTF8Strings can only represent U+ to U+7FFF (allowing the possibility that some codepoints above U+10 may be assigned in the future, contrary to current policy). (OpenSSL may or may not accept the CESU-8 and Java Modified UTF-8 encoding variants and may or may not normalize those to real UTF-8 before further processing). PrintableString can only represent a specific small set of Unicode code points T61String can only represent a different specific small set. T.61 has no "well defined" bidirectional mapping with UTF8. That said, T.61 was withdrawn before 1993 (IIRC) and shouldn't be used. -- Erwann ABALEA - yétiscopique: relatif à certaines vapeurs des sommets himalayens __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
man req Then look for the "-utf8" argument. I took your example below, added "-utf8" argument, and it worked. You can display the content with "openssl req -text -noout -in blabla.pem -nameopt multiline,utf8,-esc_msb" Le 16/12/2011 16:33, Lou Picciano a écrit : openssl req -new -sha1 -nodes \ -nameopt multiline,show_type \ -keyout private/THORSTROM.key \ -out csrs/THORSTROM.csr \ -subj "/O=ESBJÖRN.com/OU=Esbjörn-Thörstrom Group/CN=Áki Thörstrom" -- Erwann ABALEA - vésicosufflochromateur: supérieur à 0,5 gramme
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 17:57, Mick a écrit : On Friday 16 Dec 2011 16:23:52 you wrote: man req Then look for the "-utf8" argument. I took your example below, added "-utf8" argument, and it worked. You can display the content with "openssl req -text -noout -in blabla.pem -nameopt multiline,utf8,-esc_msb" Would using -utf8 resolve the original OP problem? To create the request/certificate, yes. This is what I do to embed accented characters in UTF8. Typing openssl req -utf8 -new -nodes -newkey rsa:512 -keyout THORSTROM.key -out THORSTROM.csr -subj "/O=ESBJÖRN.com/OU=Esbjörn-Thörstrom Group/CN=Áki Thörstrom" on an UTF8 capable terminal, with a "string_mask = utf8only" in the right openssl.cnf file, gives me a certificate request correctly encoded in UTF8 with the wanted characters in the DN. -- Erwann ABALEA - minilactopotage: intense satisfaction
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 16:29, Jakob Bohm a écrit : On 12/16/2011 3:22 PM, Erwann Abalea wrote: Le 16/12/2011 15:07, Jakob Bohm a écrit : I think we may have a bug here, anyone from the core team wish to comment on this. The apparent bug: When enforcing the "match" policy for a DN part, openssl reports an error if the CSR has used a different string type for the field, but the correct value (The naively expected behavior is to realize the strings are identical and use the configured encoding for the resulting cert). Do you expect the "openssl ca" tool to apply the complete X.520 comparison rules before checking the policy? Not unless there are OpenSSL functions to do the work. Otherwise I just expect it to apply the character set conversions it uses for its other operations (such as reading the config file/displaying DNs). Fair. I personally use the openssl command line tools to have a quick CA, not a full-featured one. The API is complete and allows to code this. But you're right, it would be fair to have consistent behaviour. 3. Validating a certificate whose issuing CA certificate specifies path constraints where the issued certificate satisfies the path constraint except for the exact choice of string type. NameConstraints is a set of constraints imposed on the semantic value of the name elements, not on their encoding (string type, double-spacing, case differences, etc). The question was how the OpenSSL code (library and command line) handle the scenario, your answer seems to indicate that it is indeed supposed to compare the semantic character sequence, not the encoding. That's what X.509 and X.520 impose. An algorithm is described in X.520 for name comparisons. T.61 has no "well defined" bidirectional mapping with UTF8. That said, T.61 was withdrawn before 1993 (IIRC) and shouldn't be used. According to RFC1345, T.61 has a well defined mapping to named characters also found in UNICODE. Some of those are encoded as two bytes in T.61 (using a modifier+base char scheme), the rest as one byte. That is what I mean by a bidirectional mapping to a small (sub)set of UNICODE, meaning that most UNICODE code points cannot be mapped to T.61, but the rest have a bidirectional mapping. I'm not finished with the reading of T.61 (1988 edition), but here's what I found: - 0xA6 is the '#' character, 0xA8 is the '¤' character (generic currency), but those characters can also be obtained with 0x23 and 0x24, respectively (Figure 2, note 4). Later in the same document, 0x23 and 0x24 are declared as "not used". This is both ambiguous and not bidirectional. - 0x7F and 0xFF are not defined, and are not defined as "not used". - 0xC9 was the umlaut diacritical mark in the 1980 edition, which is still tolerated in the 1988 edition, but the tables don't clearly define 0xC9 (and again, don't define it as "not used"). 0xC8 is declared as "diaresis or umlaut mark". As I don't have the 1980 edition, I don't know if it was already the case. - nothing is said if a diacritical mark is encoded without a base character. These are ambiguities. Annexes define control sequences (longer that 2 bytes), graphical characters, configurable character sets, presentation functions (selection of page format, character sizes and attributes (bold/italic/underline), line settings (vertical and horizontal spacing)). I doubt everything can be mapped to UTF8. Constructing a mapping table from the data in RFC1345 or other sources is left as an exercise for the reader (cheat hint: Maybe IBM included such a table in ICU or unicode.org included one in its data files). I think only a subset of T.61 is taken into consideration. But I haven't looked at the hinted files. -- Erwann ABALEA - D'abord, on est sur le web, pas sur ce usenet dont on nous rabbache les oreilles et qui n'est qu'une abstraction. -+- JP in http://neuneu.ctw.cc - Neuneu en abstract mode -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 18:27, Jakob Bohm a écrit : On 12/16/2011 6:14 PM, Erwann Abalea wrote: Le 16/12/2011 17:57, Mick a écrit : On Friday 16 Dec 2011 16:23:52 you wrote: man req Then look for the "-utf8" argument. I took your example below, added "-utf8" argument, and it worked. You can display the content with "openssl req -text -noout -in blabla.pem -nameopt multiline,utf8,-esc_msb" Would using -utf8 resolve the original OP problem? To create the request/certificate, yes. This is what I do to embed accented characters in UTF8. Typing openssl req -utf8 -new -nodes -newkey rsa:512 -keyout THORSTROM.key -out THORSTROM.csr -subj "/O=ESBJÖRN.com/OU=Esbjörn-Thörstrom Group/CN=Áki Thörstrom" on an UTF8 capable terminal, with a "string_mask = utf8only" in the right openssl.cnf file, gives me a certificate request correctly encoded in UTF8 with the wanted characters in the DN. Sorry, but OP's problem seems to be that the CSR was created by "some software embedded in a router", Sorry, I replied to the problem described by Lou Picciano, and forgot that Mick was the OP. My fault. -- Erwann ABALEA - Le netétiquette n'est qu'une vaste fumisterie,il faut de l'argent pour fonctionner,à force,en France de refuser tout rapport sain avec l'argent,l'on riqsque de tuer ce nouvel outil. -+- AA in: Guide du Neuneu d'Usenet - Le netétiquette du riche -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 18:45, Mick a écrit : [...] Indeed, the message was rather esoteric and it did not offer a way out - e.g. it could have advised to change "match" to "supplied" in openssl.cnf, or to ensure that the encoding between the CSR and ca is the same. I think what confused me is that by uploading the cacert to the router I would expect the router to respect the cacert's encodings. It evidently did not. It doesn't need to :) Since I cannot change the router firmware, what should I change the 'string_mask = ' on the PC to agree with the router? My understanding is that string_mask is used when producing an object (request or certificate), not when checking its content with the policy match directives. You could either regenerate your CA with string_mask set to "default" (which means: first try "PrintableString", then "T61String", then "BMPString"). Your router uses PrintableString for pretty much anything except commonName, which is encoded in T61String. That could work. Or you could keep your CA certificate as is, change the policy directives (from "match" to "supplied"), and manually check the requests. Or code something with "openssl req -text -nameopt multiline,utf8,-esc_msb ...", extracting the RDNs, comparing with what is set in the CA certificate (the "-nameopt ..." argument will convert everything into UTF8, easing the comparison), whence performing your own validation. -- Erwann ABALEA - Désolé. Ta gueule. -+- LC in : Guide du Neuneu Usenet - Neuneu exaspère le dino -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: stateOrProvinceName field problem when signing CSR
Le 16/12/2011 19:07, Jakob Bohm a écrit : On 12/16/2011 6:47 PM, Erwann Abalea wrote: Le 16/12/2011 16:29, Jakob Bohm a écrit : On 12/16/2011 3:22 PM, Erwann Abalea wrote: NameConstraints is a set of constraints imposed on the semantic value of the name elements, not on their encoding (string type, double-spacing, case differences, etc). The question was how the OpenSSL code (library and command line) handle the scenario, your answer seems to indicate that it is indeed supposed to compare the semantic character sequence, not the encoding. That's what X.509 and X.520 impose. An algorithm is described in X.520 for name comparisons. I understand, but does OpenSSL implement that? In the API, yes. At least in 1.0.0 branch, which passes the NIST PKITS suite. I'm not finished with the reading of T.61 (1988 edition), but here's what I found: - 0xA6 is the '#' character, 0xA8 is the '¤' character (generic currency), but those characters can also be obtained with 0x23 and 0x24, respectively (Figure 2, note 4). Later in the same document, 0x23 and 0x24 are declared as "not used". This is both ambiguous and not bidirectional. As you quote it (I don't have a copy), this sounds like using 0x23 and 0x24 should not be done when encoding, but should be accepted when decoding. Yes, and that also means those characters cannot be obtained with "7-bit T.61", contrary to the table found in RFC1345. In fact, there's no "7-bit T.61" set, so I don't really know how RFC1345 should be treated. - 0x7F and 0xFF are not defined, and are not defined as "not used". RFC1345 seems to indicate that 0x7F maps to U+007F DEL This mapping (0x7F - DEL) is only presented in Annex E, discussing the greek primary character set. But the Table 2, which exhaustively lists the codes, avoids 0x7F (07/15, really). Some PKI toolkits use T.61 to encode ISO8859-1 characters, and ISO8859-1 defines 0x7F as "DEL". Annexes define control sequences (longer that 2 bytes), graphical characters, configurable character sets, presentation functions (selection of page format, character sizes and attributes (bold/italic/underline), line settings (vertical and horizontal spacing)). I doubt everything can be mapped to UTF8. Most of those would be inapplicable to the encoding of X.500 strings, configurable character sets sounds like an ISO-2022 like mechanism useful for encoding an even larger subset of UNICODE, as do graphical characters. However none of those features were mentioned in the still available secondary references I looked at (RFC1345 and Wikipedia), so they are unlikely to be accepted nor emitted by any current implementations of T.61. Sure. But those are valid T.61 sequences anyway. As you said, RFC1345 lists historic character sets, and T.61 is one of them (if predates Unicode). T.61 was ambiguous, was defined for a now obsolete system (Teletex), was more than a simple character set (you could redefine graphical characters, and specify formatting), and is now withdrawn since nearly 2 decades. It's time to avoid it :) -- Erwann ABALEA - préhibernoluthidolichospasmes: sanglots longs des violons de l'automne, phénomène météomusical aux propriétés homéoanémicardiomutilatoires, décrit pour la première fois par Verlaine en 1866 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] deff hellman
Bonsoir, This is an english spoken mailing list, so I'll reply in english. With Diffie-Hellman, g (the generator) is public, and can thus be shared by all the actors (nodes, in your study). Each actor's private key (a or b in your example) is used only once and discarded at the end of the session, or you lose the forward secrecy ability. In your study, you could either build a session key with each individual node participating in the session, or all the participating nodes could generate a common session key: - Alice, Bob, and Carol all choose their private keys (a, b, c) - Alice sends g^a to Bob - Bob sends (g^a)^b to Carol - Carol computes ((g^a)^b)^c and keeps it secret - Bob sends g^b to Carol - Carol sends (g^b)^c to Alice - Alice computes ((g^b)^c)^a and keeps it secret - Carol sends g^c to Alice - Alice sends (g^c)^a to Bob - Bob computes ((g^c)^a)^b and keeps it secret - Alice, Bob, and Carol share the same secret: g^abc If you carefully choose p (size and factors of p-1), then you don't have to worry about finding a given g^a mod p. Look for "General Number Field Sieve" to get numbers, this is the most efficient algorithm so far, with large enough p. In your presented study, authentication is left aside. That's good for a school study, but not for real life work. Le 19/01/2012 17:01, BENAMAR Lydia a écrit : Bonsoir, dans le cadre de notre projet de fin d'étude, nous sommes amenées à utiliser la technique de Deff Hellman afin d'initier une session entre la source des paquets et tous les noeuds du chemins. si vous permettez on a quelques questions à vous poser. est ce que la source peut échanger le même g et a avec tous les noeuds du chemin? quel est le temps nécessaire pour un attaquant qui écoute les valeur g^a et g^b pour connaitre g^ab? quel algorithme est le plus approprié en terme d'efficacité et de consommation des ressources? en attente de toute suggestion, acceptez nos salutations. -- Erwann ABALEA - caïssaphique: se dit d'une lesbienne qui joue aux échecs. (Caïssa est la déesse des échecs) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Support for certificates other than the X509 standard Reg.
Bonjour, Out of my head, there's ISO7816-6 certificates, used at least in eID projects (EAC passports). One can also mention PGP/GPG (which can now include X.509), with a marginal use (in corporate/business world). OpenSSL has a great support for X.509, of course, but since it also includes complete ASN.1 and crypto API, you can easily work with ISO7816-6 certificates. I haven't used PGP/GPG since a few years so I don't really know if there's an ASN.1 description, but the crypto is the same, for sure. Le 31/01/2012 17:07, Ashok C a écrit : I understand that X509 is the preferred ITU-T standard for PKI. But what would be the other certificate standards which are available and those which a PKI solution needs to support? First question would be whether there are any certificates which do not belong to the X509 standard? Also, what all standards of certificates does the openSSL implementation support? -- Erwann ABALEA - Depuis ce matin, j'ai une IP en 213.@@@.@@@ et des plumes. C'est devenu apparement une IP statique. Mon contrat me donne droit à une IP dynamique.. -+- TW in<http://neuneu.mine.nu> : Neuneu se fixe -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer
Ok. Now switching to openssl-users mailing list, sorry for RT moderators and OpenSSL developers. Tamir, We are not speaking about different things. You either fail to understand, or fail to explain, and you're constantly using wrong terms. For example, what you provided is *not* a certificate, it is an RSA private key. That's absolutely not the same thing. In this private key, exponent1, exponent2 and coefficient are encoded with different lengths because they *are* of different lengths. Is there anything somewhere preventing these numbers to be of different lengths? In other terms, is there any formal document stating that these elements MUST be of equal lengths? I haven't paid for the ISO8825 document, but I have its free ITU-T version, X.690 (it's the same text). Below is paragraph 8.3 if this standard: - 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. - Where in this text is said that a sequence of integers must be encoded with the same length? Could you take your provided example of a badly encoded key and provide a representation of what would be a good encoding, clearly? My guess is that you would like to have an additional leading 00 octet in exponent2' serialization. That would give the following encoding: 02 41 00 00 80 5B 5F BB 4F 28 E4 EA 7A 19 52 55 37 81 14 AA B3 D3 34 51 A5 A8 91 28 82 AE 58 3F 80 36 27 48 20 88 E1 08 C0 A8 46 16 64 86 FF 9E CD 5D 9E 48 42 BF 25 F8 47 85 91 E4 A2 13 71 0A C1 C7 A9 Am I right? If my guess is correct, then you need to re-read the 8.3 paragraph again and again. Rule 8.3.2 states that bits of the first octet and bit 8 of the second octet (of the content octets) can not be all zero. This example doesn't follow the rule. Your supposedly-bad provided example does. Le 03/04/2012 11:34, Tamir Khason via RT a écrit : It seemed that we are speaking about different things. In certificate i pasted, integers used for exponent1, exponent2 and coefficient encoded with different lengths. In chapter 8.3 of ISO 8825 there is clear statement of how integer values should be encoded. All need is to take those numbers from "bad" certificate i pasted and encode it by using different 8825 implementations to see leading zeros appear. When openssl encode those number leading zeros are missing. This is what i claim as a bug. On Tue, Apr 3, 2012 at 11:58 AM, Erwann Abalea via RT wrote: Le 03/04/2012 09:38, Tamir Khason via RT a écrit : Please see decrypted private key http://pastebin.com/DzYLnHZT Thanks. You didn't provide information on where you think the error is, precisely. I'll base my answer on your previous posts. You started to say that "the coefficients should be of the same length". By "coefficient", you mean the CRT parameters (exponent1, exponent2, coefficient). You didn't provide an authority source to back up this assertion. In fact, it's false, and has been explained why. There's no optimization trick, no particular decision, some parameters can be smaller than others, that happens, and it's not wrong. You then talked about end-of-content octets. There's no such octet in the provided example. And there's no end-of-content octet possible in the DER representation of an object. End-of-content octets are found with indefinite length objects, when you don't know in advance the size of the object you're encoding, but can tell when it ends; think of it as "streaming", for example. This is allowed with BER only, not DER. It was explained to y
Re: [openssl-users] Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer
Le 04/04/2012 05:22, Curt Sampson a écrit :
[...]
In fact, if one can be encoded in a shorter form than the other, it MUST
be encoded in that shorter format. This is because certificates use DER,
not BER, and DER says that.
As pointed by Peter Sylvester, BER doesn't allow useless leading 00
octets either in the content.
The content MUST be serialized with the lowest possible number of
octets. The difference between BER and DER for integers encoding is on
the length encoding ("02 81 01 01" is valid BER, not valid DER; "02 01
00 01" is neither valid BER nor DER).
--
Erwann ABALEA
-
N'ouvrez aucun message ayant pour objet RETURNED OR ENABLE TO DELIVER.
ce virus se greffe tout seul à tout les composants de votre ordinateur
et les détruit. Ce message vous est envoyé par l'équipe du QUICK DRIVE
-+-AL in: Guide du Neuneu Usenet - Le virus Mad Cow frappe encore -+-
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] RES: Random number generator
It replies '42' everytime. And that's a good answer. Le 05/04/2012 13:35, Leonardo a écrit : I'd like to add some question about this. What kind of RNG is implemented? Linear Congruential generator? Is it another more sophisticated? Thanks Leonardo *De:*owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] *Em nome de *Prashanth kumar N *Enviada em:* quinta-feira, 5 de abril de 2012 01:07 *Para:* openssl-users@openssl.org *Assunto:* Re: Random number generator You can use the below API's RAND_bytes() RAND_pseudo_bytes() On Thu, Apr 5, 2012 at 12:33 AM, Jeremy Farrell mailto:jeremy.farr...@oracle.com>> wrote: http://lmgtfy.com/?q=openssl+random+number > From: Alex Chen [mailto:alex_c...@filemaker.com <mailto:alex_c...@filemaker.com>] > > There is a 'rand' command in the openssl command line tool to generate > 'pseudo' random number generator. But I cannot find the API from > either the 'ssl' or 'crypto' man pages. > Can someone point me to the API page if it is available? > > Is this RNG implementation different in the regular distribution and > the FIPS Object module? __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org <mailto:openssl-users@openssl.org> Automated List Manager majord...@openssl.org <mailto:majord...@openssl.org> -- Erwann ABALEA - Ca fait déjà plusieurs semaines que j"essaie de correspondre par l" intermédiaire d"un groupe de discussion. Ca ne fait que deux jour que je suis parvenu à expédier un message -+- GM in GNU : Patience et longueur de temps.. -+-
Re: [openssl-users] Re: WHat is NID_subject_key_identifier
Hodie IV Id. Iun. MMIX, Satish Chandra Kilaru scripsit: > I found relevant information in RFC 3280. I recommend referring to > that RFC for any questions like mine. > http://www.ietf.org/rfc/rfc3280.txt Switch to RFC5280, which obsoleted RFC3280 more than one year ago. -- Erwann ABALEA - Aiming at foot before pulling trigger always bad idea. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] UltraSPARC T2 - OpenSSL - PKCS11 ???
Hi, Hodie Id. Aug. MMIX, CH-Kami scripsit: > I'm currently working on a project involving a Sun T5120 and some crypto... > (I'm also new to OpenSSL & T2) > > T2 is supposed to be quite fast for crypto operations : > > openssl speed rsa >signverifysign/s verify/s > rsa 1024 bits 0.0246s 0.0014s 40.7701.3 > > openssl speed -engine pkcs11 rsa > signverifysign/s verify/s > rsa 1024 bits 0.s 0.s 25112.3 30151.4 > > Compaired to the first speed test it looks pretty good ! > > To give me an idea how fast it is, I've run the same test on a desktop > machine: > signverifysign/s verify/s > rsa 1024 bits 0.000835s 0.41s 1197.1 24520.1 The T2 runs at a lower frequency, and you're testing only 1 core, and 1 thread. Do your tests using "-multi 16" option, to saturate all your CPUs/cores/threads. On my laptop (Core2 duo 2GHz), this is what I get: signverifysign/s verify/s rsa 1024 bits 0.001340s 0.58s746.4 17313.2 Adjust the "16" to the number of CPUs in your T5200 (I tried with a T2000, equipped with 1 CPU, 4 cores, 4 threads/core). -- Erwann ABALEA - I can't be stupid, I completed third grade! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How to set CA:TRUE, in an existing cert
Hello, Hodie IV Id. Mai. MMX, Darázs Attila scripsit: > Please help me figure out this. I'm trying to add the CA:TRUE > constraint to one of my existing cert (the GTE CyberTrust Global Root, > actually, can be downloaded here: > http://ugykezelo.elte.hu/files/gte-cybertrust-global-root.crt ). First, you can't modify an existing certificate without invalidating its signature. Second, this certificate is a V1 one, and extensions were added to V3 of the X.509 standard. You can't then add the basicConstraints extension. > Explanation why I need this: > I'm trying to install a CA cert on my Android phone, to use my > university WiFi account, via http://www.realmb.com/droidCert/ I would > need to install the GTE CyberTrust Root cert, but it is getting > registered as a client cert, not a CA one. If I try to install one > with CA:TRUE, then it's working properly. -- Erwann ABALEA - Computers can never replace human stupidity. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Private Key Usage Period
Hodie XIV Kal. Iun. MMX, Dr. Stephen Henson scripsit: > On Wed, May 19, 2010, Eisenacher, Patrick wrote: > > > Hi Bram, > > > > > -Original Message- > > > From: Bram Cymet > > > > > > I am wondering if with the latest version of Openssl it is possible to > > > set the Private Key Usage Period extension and if so what is > > > the format > > > of the parameters? > > > > this is how I do it in my config file: > > > > [ ca_ext ] > > basicConstraints = critical, CA:true > > subjectKeyIdentifier = hash > > authorityKeyIdentifier = keyid > > keyUsage = critical, cRLSign, keyCertSign > > 2.5.29.16 = ASN1:SEQUENCE:privateKeyUsagePeriod > > > > [ privateKeyUsagePeriod ] > > notBefore = IMPLICIT:0,GENERALIZEDTIME:$ENV::PRIV_KEY_START > > notAfter = IMPLICIT:1,GENERALIZEDTIME:$ENV::PRIV_KEY_END > > > > Then my script sets PRIV_KEY_START and PRIV_KEY_END to their proper values > > in generalized time format and exports them before invoking the ca command. > > Works like a charm. Nicely done. I always appreciate OpenSSL configuration options when I need to provide some hand-made certificates. > Yes that will work. Instead of the numerical OID the shortname > "privateKeyUsagePeriod" should work too. > > OpenSSL doesn't currently include a routine to set the extension directly: it > was marked as deprecated by PKIX for a number of years. Yes, and ICAO choosed to include it in CSCA and DS certificates (all this is for biometric passports), while referring to RFC3280/5280 as a basis. Strange. But they made other mistakes, much bigger ones, so :) -- Erwann ABALEA Département R&D KEYNECTIS 11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France Tél.: +33 1 55 64 22 07 http://www.keynectis.com - What we have here is a failure to communicate. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: NameConstraints are not being applied (or I don\'t know how to enforce them?)
Hodie III Non. Iun. MMX, Victor Duchovni scripsit: > On Thu, Jun 03, 2010 at 02:32:10PM -0400, jeff wrote: > > > > I would expect such constraints to only apply when > > > certificates are being *verified*. There seems to be > > > little point in preventing a CA from attempting to sign > > > violating certificates. > > > > Yes I later tried to "verify" and I still got no complaints. > > As I said, the "verify" command only checks the trust chain, peer name > verification, is not in scope. It could fail to validate the chain, given the fact that the extension is set critical, and not handled, even if recognized. -- Erwann ABALEA - When birds fly in the right formation, they need only exert half the effort. Even in nature, teamwork results in collective laziness. Demotivators, 2001 calendar __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Support of SHA-2
Hodie V Id. Aug. MMX, Jakob Bohm scripsit: > On 08-08-2010 01:13, Dr. Stephen Henson wrote: [...] > >It depends on what you mean by "in". Support for SHA-2 algorithms is in > >OpenSSL 0.9.8 and later. The algorithm can be used in certificates and CMS > >for > >example. > > > >Since OpenSSL doesn't currently support TLS 1.2 it will not be used for TLS > >ciphersuites since none in TLS 1.1 or earlier use SHA-2 algorithms. > > I believe this is an unfortunate reading of the RFCs. Fundamentally, > the SSL3/TLS protocols do not tie the availability of a cipher suite to > the version of the protocol document which was current when it was > introduced. The fact that the most common cipher suites are defined in > the same documents as the protocols themselves really should not be > treated as more important than the fact that there is a single IANA > registry for these values. > > Formally: RFC2246, RFC4346 and RFC5246 all refer to IANA for the cipher > suite list. RFC2246 doesn't refer to this IANA registry (RFC2434, a later one). RFC4346/5246 do. > IANA's cipher suite list refers to different RFCs for > different suite values, including RFC2712 and RFC5246. The cipher > suites so defined are thus equally applicable to the TLS versions (1.0, > 1.1 and 1.2) defined in RFC2246, RFC4346 and RFC5246 unless there is > a cipher suite specific reason not to use them with specific TLS > versions. > > Of cause using an SHA-2 based cipher suite with TLS 1.1 or older implies > that the keys will still be created from a master secret produced using > the old MD5/SHA-1 PRF. But at least the HMACs for the data will be done > with SHA-2 , thus limiting the attack surface for exploiters of SHA-1 > weaknesses. This is not possible, as the ciphersuites defined by RFC5246 all use P_SHA256 as the PRF (paragraph 1.2). In paragraph 5, it is said "New cipher suites MUST explicitely specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function". That's precisely what is done, since new ciphersuites use P_SHA256 as the PRF. Using the old PRF with the new ciphersuites is not standard at all. -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Support of SHA-2
Hodie V Id. Aug. MMX, Erwann ABALEA scripsit: [...] > This is not possible, as the ciphersuites defined by RFC5246 all > use P_SHA256 as the PRF (paragraph 1.2). > In paragraph 5, it is said "New cipher suites MUST explicitely specify > a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a > stronger standard hash function". That's precisely what is done, since > new ciphersuites use P_SHA256 as the PRF. Using the old PRF with the > new ciphersuites is not standard at all. I just checked NSS (3.12.6) and GNUTLS (2.11.0). NSS doesn't support TLS1.2 at all, neither the protocol nor the ciphersuites. Some code needs to be adapted to specify the PRF to be used. GNUTLS supports TLS1.2, with its ciphersuites, and all the new ciphersuites use SHA256 as the PRF. If a new ciphersuite with a stronger hash function is defined as its PRF, then GNUTLS would have to be modified (right now the selection of the PRF is done by the TLS version from which the ciphersuite is issued). So, using the old PRF with new ciphersuites is nonstandard, but could also lead to interoperability problems. -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Support of SHA-2
Hodie IV Id. Aug. MMX, Alex Chen scripsit: > I am only a end user and not familiar with SSL internal. If I > understand the replies correctly, OpenSSL 1.0.x currently supports > SHA-2 in certificates but not in the cipher suites used in network > communication protocol. Is that a correct statement? That's it. OpenSSL implements the SHA2 family and is able to use wherever it needs to (certificate+CRL, CMS, ...), but only implements TLS1.0 (and in a near future TLS1.1) protocol. SHA256 (member of the SHA2 family) is defined in ciphersuites defined by TLS1.2, and these ciphersuites (and the protocol itself) need to be used differently than what was done previously. -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Support of SHA-2
Hodie IV Id. Aug. MMX, Jakob Bohm scripsit: [...] > The issue is which PRF to use when TLS version <= 1.1 but ciphersuite > is from RFC5246 Appendix A. The TLS 1.1 and older standards then > insist on the old PRF no matter what cipher suite is used, while the > cipher suite definitions (in RFC5246 Appendix A) specify a PRF function > aspect, which the old TLS versions do not know about. That's right. This notion of a ciphersuite-selected PRF doesn't exist for TLS1.1 and older protocols, and TLS1.2 defined new ciphersuites all specify SHA256 as the PRF. Using these ciphersuites with the old PRF would then be invalid. Enforcing this would be problematic, since you keep the same cipher identifiers on the wire, with different behaviours depending on the protocol. > You did not state if GNUTLS can use the new ciphersuites with a TLS > version <= 1.1 and what it does in that situation, could you please > check that specifically, as you seem to have the right part of the > GNUTLS code handy. Reading the source, the ciphersuite list is built by removing ciphers not valid with the negociated protocol version. Whence, TLS1.2 ciphersuites can't be used with a TLS1.1 or older connection. That's confirmed by analyzing what is sent on the wire (a GNUTLS client talking to an Apache+mod_ssl server). If this check is removed, I think the PRF function used will be based on the protocol version, not the selected cipher. TLS1.2 will use SHA256, any other will use the old MD5+SHA1. Anyway, if you modify the source, you can do anything you want. -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] Re: Verify X.509 certificate, openssl verify returns bad signature
Hodie IV Kal. Sep. MMX, Mounir IDRASSI scripsit: [...] > Specifically, Peter Gutmann in his X.509 Style Guide says this about this > field : "If you're writing certificate-handling code, just treat the > serial number as a blob which happens to be an encoded integer". This is the kind of advice that pushes programmers to allocate fixed size fields in databases, and consider a certificate's serial number to always fit the size. This is also bad in practice. -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Another problem with certificate verification...
Hodie III Kal. Sep. MMX, Tomás Tormo scripsit: [...] >[amsterdam:/morralla/ttormo/ACIndenova]# openssl x509 -in acindenova.cer >-text [...] > Not Before: Dec 8 08:31:12 2006 GMT > Not After : Dec 5 08:41:12 2016 GMT [...] >[amsterdam:/test]# openssl x509 -in admesigna.cer -text >Certificate: [...] > Not Before: May 10 12:25:25 2010 GMT > Not After : May 7 12:35:25 2020 GMT [...] Maybe OpenSSL doesn't like the fact that your EE certificate lasts longer than its CA? Anyway, other things: - e=3 is not considered good - will your Root CA sign something else than certificates and CRLs? If not, there's no use for the digitalSignature flag in keyUsage extension - a CRLDP in a Root is useless. Trust comes off-band, end of trust will also come off-band - a certificatePolicies extension in a Root is useless, it won't be processed at all if one follows the normative algorithm - netscapeCertType is of no use in 2010 - in your EE cert, qcStatements extension, you placed the 0.4.0.1862.1.1 OID twice. Useless, once is enough - in your EE cert, you added an AIA extension with an empty OCSP URI. Bad. - in your EE cert, you added an AIA extension with a CAIssuers field, but the considered CA is a self-signed one, so it has no other issuer than itself, so it's useless - in your EE cert, you specified a policy in your certificatePolicies extension. While this particular example is correct, that's just because a compliant implementation will ignore the OID used on the Root. If a non compliant one takes the Root OID in consideration, then it will fail -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Verify X.509 certificate, openssl verify returns bad signature
Hodie III Kal. Sep. MMX, Goran Rakic scripsit: [...] > I read the other messages in this thread, but I am not an expert in the > field so I do not know if openssl should add a support for "incorrect" > serial numbers. In RFC 3280 there is a note about "Non-conforming CAs" > where section "4.1.2.2 Serial number" is saying that "certificate users > SHOULD be prepared to gracefully handle such certificates". Maybe the > note can apply in this case? > > What I do know is that without a patch openssl can not be used with > certificates issued on a Serbian national eID card. At least one other > Serbian CA is hit by the same problem (http://ca.pks.rs/certs/) where > PKI solution was provided by a same company. These are not X.509 certificates, since they're not correctly encoded (not DER, not even BER). The paragraph you're mentioning is about the value of the serial number (strictly positive, no more than 20 bytes), not about its encoding. A serial number can be negative, or larger than 20 bytes when encoded, if your only goal is to be X.509 compliant, and not RFC5280 compliant. Whence, "non-conforming CAs" here is to be understood as "non-RFC5280-conforming CAs". Those certificates should have been rejected by any correct validator (human or machine) before going into production. The serial number is encoded using 4 bytes as its value, it should be 1 byte only. -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] **Spam** Problem verifying a chain...
Bonjour, Hodie post. Kal. Sep. MMX, John Doe scripsit: > I have some issues with chained certificates. > I am trying to verify my certificate with the intermediate certificate of my > registrar... > > my.crt: > Issuer: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA > Subject: OU=Domain Control Validated, OU=Gandi Standard SSL, CN=my.site.com > > gandi.crt: > Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, > OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware > Subject: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA > > # openssl verify -CAfile gandi.crt my.crt > my.crt: /C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA > error 2 at 1 depth lookup:unable to get issuer certificate It wants to check the issuer's certificate of Gandi. You can find it in your browser, or maybe in a decently installed Ubuntu/Debian, in /etc/ssl/certs directory (UTN_USERFirst_Hardware_Root_CA.pem on my machine). -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Max length of company field
Hodie V Id. Iun. MMVIII est, Dr. Stephen Henson scripsit: > On Mon, Jun 09, 2008, Florian Lindner wrote: > > > No, the name "long Name" was only a placeholder. "problems making > > Certificate Request" was the error message from openSSL. > > > > The real name is "GIMIK Systeme - Gesellschaft fЭr innovative Marketing- & > > Kommunikationssysteme mbH" which is 82 characters long. Is there a way to > > work around the 64 char limit? > > There is a limit in openssl.cnf and also a hard limit imposed by the OpenSSL > source. The 64 character limit is mandated by RFC3280 which OpenSSL enforces. > The only way to change that is to modify the OpenSSL sources. If you really > want to do that it is in asn1.h as ub_organization_name. RFC3280 (superseded by RFC5280, btw), is less flexible than the X.509 standard for this point, and with "not so good" arguments. X.509 standard defines organizationalUnitName as a DirectoryString of up to length ub-organizational-unit-name characters, as does the RFC5280, but it defines this upper bound as 64 characters in a non normative annex (i.e. it hapilly defines limits, it can even propose one as an example, but let the implementer choose what's best for its environment). RFC5280, on the other hand, states that the upper bounds MUST be enforced, and cites X.411 standard as the source, despite the fact that this has nothing to do with X.500. This could force some companies to change their name (the same logic is applied to the OrganizationName field). An X.509 certificate can be viewed as an ID, and has to map to the real world the most possible. Being unable to represent the name of a company or the name of an individual because of a "one size fits it all" decision, in an electronic world, is a shame (that's my opinion). -- Erwann ABALEA <[EMAIL PROTECTED]> - Mammifère : se dit d'un animal à squelette, poilu, qui donne du lait. Exemple : une noix de coco. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: Which datatype for passphrase?
Hodie Id. Iun. MMVIII est, Konrad Kleine scripsit: > To make this thread a little more interesting... Why are there more than > 6200 "gotos" in the OpenSSL source code? Provokating question, I know. Because C is not BASIC? ;) Honestly, I also disliked gotos in the past, with bad reasons; I changed my mind, it allows me to write functions with only one exit point, and group deallocations together. There's no "spaghetti" symptom, in C, as a goto must span in the same function. -- Erwann ABALEA <[EMAIL PROTECTED]> - If you're not part of the solution, there's good money to be made in prolonging the problem. Demotivators, 2002 calendar __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] RE: Certificate creation stuck at 256 certificates
Hodie VII Id. Aug. MMVIII est, David Schwartz scripsit: > > > I have had a look around and it appears that the serial number > > for the > > last certificate created was FF (hex), indicating 256 > > certificates have > > so far been created. The next number in the serial file is 0100, > > which > > would seem the logical next number, however the certificate > > signing > > bails out on me. > > FF is not a legal certificate number. Certificate numbers must not be > negative. (0xFF has the sign bit set and hence is negative.) "Legally" (this term has nothing to do here) a serial number *can* be negative, if you're looking at the X.509 recommendation. That's surely not the reason of the problem. Only the RFC (starting with 3280) states that the serialNumber MUST be a positive integer. -- Erwann ABALEA <[EMAIL PROTECTED]> - ``Do or do not. There is no try." Yoda __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: any reference to different certificate versions
Hodie XIV Kal. Sep. MMVIII est, Kyle Hamilton scripsit: > X.509 refers to the certificate version. 0 == version 1, 1 == version > 2, 2 == version 3. > > Version 1 certificates have no means for any extensions. > Version 2 certificates are CRLs. ? Version 2 certificates have "issuerUniqueIdentifier" and "subjectUniqueIdentifier" fields just after the subjectPublicKeyInfo. These are highly deprecated (I haven't seen any in the field). Version 3 certificates added support for extensions, after the 2 previously mentioned fields. CRLs exist since X509v1. > Version 3 certificates are the current norm, and most likely what you want. > > The best reference currently is RFC5280, and all of its references. X.509 standard is (my) best reference, on top of which RFC5280 adds some additional MUST, SHOULD, etc. (I disagree on some of them, that's why I prefer X.509, but it's a matter of choice). Oh, X.509 is free to download from the ITU-T website, as is the whole X.5xx group of documents, and most of the X.6xx (680 and 690 comes to mind, for ASN.1 and its encodings). That wasn't the case some months/years ago. -- Erwann ABALEA <[EMAIL PROTECTED]> - Keyboard not connected, press to continue. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: X509 V1 version info
Hi,
Hodie Kal. Sep. MMVIII est, Madhusudhan reddy scripsit:
>Thanks for the reply. What i mean here is while loading X509
>V1 certificate using the API "PEM_read_bio_X509_AUX(), the verisn filed
>itself is null, not the value. Pls check the attached .jpg for the screen
>shot.
The version field is defined as:
version [0] EXPLICIT Version DEFAULT v1
The Version type is defined as:
Version ::= INTEGER { v1(0), v2(1), v3(2) }
DEFAULT implies OPTIONAL, and if this field is absent, then it has to
be considered a version 1 certificate.
I saved your certificate (a VeriSign one, it seems) to a file, and
checked its signature:
openssl verify -CAfile rootv1.pem rootv1.pem
which replied "Ok".
Do you have a better example of a "bad" certificate?
--
Erwann ABALEA <[EMAIL PROTECTED]>
-
I can't be stupid, I completed third grade!
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Put certificate on hold
Hello Martin, Hodie III Id. Oct. MMVIII est, Martin Schneider scripsit: > As far as I understand things, you can either revoke a cert (which is > not reversible) and you can put a cert "on hold". Right. > "Holding" a cert is a reversible process; meaning you can "un-hold" > the cert and use the SAME cert after it was un-holded. Is this true? > Putting a cert "on hold" is like revoking a cert, you only have to > provide the reason code "certificate Hold". Then an entry in the CRL > will be generated that looks like follows: In fact, the certificate is present in the CRL, but is not considered "revoked" (as per the X.509 recommendation). It's on hold, as the reason tells. For the majority of the applications, it's the same, the behaviour won't be different. But if you wan't to provide signature services that need to be verified far in the future, that's a point to consider. > What I do not understand is, how to "un-hold" the cert. What do I have > to do? Theoretically "un-holding" would mean, that you remove the > serial number of the "holded" cert from the crl? Reading the X.509 recommendation (downloadable for free from the ITU-T web site) tells us that a certificate can be "un-holded" by 2 means: - either really revoke it, by changing the reason code while keeping the date - or completely remove it from the CRL, as you guessed. If you plan to issue deltaCRLs, you MUST use the "removeFromCRL" reason code for such certificates, only for the deltaCRLs. -- Erwann ABALEA <[EMAIL PROTECTED]> - When you honestly believe you can compensate for a lack of skill by doubling your efforts, there's no end to what you can't do. Demotivators, 2001 calendar __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Wildcard certs vs. base name
Hodie pr. Id. Nov. MMVIII est, John Nagle scripsit: > Question: Is a certificate for "*.example.com" considered valid for > "example.com"? No. "*.example.com" could at most be reduced to ".example.com", but the first "." can't be suppressed. > OpenSSL seems to say no, but Firefox 2 says yes. Try > "https://stanford.edu"; for a test. The certificate sent by this site has a subjectAlternativeName extension: X509v3 Subject Alternative Name: DNS:*.stanford.edu, DNS:stanford.edu And this satisfies Firefox. > RFC 2459 doesn't discuss wildcards. I haven't paid > 73 CHF to access the X.509 standard at > "http://www.itu.int/rec/T-REC-X.509-200508-I/en";. RFC2459 is waaa obsolete, it has been replaced by RFC3280, and then by RFC5280. It can't discuss wildcards, since it's an SSL-only use case. Same goes for the X.509 standard (which is free to download in PDF format). -- Erwann ABALEA <[EMAIL PROTECTED]> - Jesus saves! Passes to Moses, he shoots. He SCORES! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Special Characters in X 509 Certificates
Hi, Hodie XIII Kal. Mar. MMIX, özgür berksoy scripsit: [...] >subjectAltName=URI:[1]http://�BOX_3:8080,DNS:�BOX_3 > >entry inside the cnf file, I get an error: > >problems making Certificate Request >1188:error:0D07A07C:asn1 encoding >routines:ASN1_mbstring_ncopy:illegal >characters:.\crypto\asn1\a_mbstr.c:162: That's normal, the \265 (I assume it's the UTF-8 U+00B5 character, for the '�', or MICRO SIGN) is not a "PRINTABLE CHARACTER", and that's what is allowed in an URI or DNSName. >Second problem is: > >Is it possible to use the same '�' character with: > >-subj /DC=�BOX_3 > >addition to the command ? When I try to do it I get the same errors in >the first problem. For the same reason. If you try to use it in a CN field, it should work. Unfortunately, it transforms it into a T61STRING, and then can't handle non ISO8859-1 characters. -- Erwann ABALEA - No wanna work. Wanna bang on keyboard. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] multiple nameConstraints
Hi, Hodie XV Kal. Apr. MMIX, Stephen Lewis scripsit: > I'm trying to create a sub-ca with name constraints for website > certificate generation with the effect that sub-ca can sign only certs > for *.mydomain.com, i.e. anything ending in .mydomain.com > > I'm trying to do this using the nameConstraints extension. I find that > if I specify a single > nameConstraints = permitted;DNS:*.mydomain.com > > then the behaviour is as desired for certs that use the > subjectAlternativeName rather than DN, for example a signed cert with Good, since the X.509 standard doesn't provide examples for pattern matching on dNSName, only for rfc822Name, and these are written as ".mydomain.com", not "*.mydomain.com". > However this is easily subverted by sub-ca issuing certs with the > website name in the CN and without a subjectAlternativeName, for example > CN=www.mybank.com passes validation, presumably because there is no > constraint on the DN included. Right. > - Is it possible to specify multiple nameConstraints in the openssl.cnf > so that both CN and subjectAlternativeName are constrained ? > > - It it possible to specify a dirName nameConstraint that allows CN to > contain *.mydomain.com where * is anything but not allow CN = anything > that does not end in .mydomain.com ? Edition 2005/08 of the X.509 has added a field in the nameConstraints extension, requiredNameForms; it allows you to explicitely require a dNSName, in order for the permittedSubTrees to do its job. Unfortunately, this field has been removed in the Corrigendum 1 published in 2007/01. Unfortunately also, it wasn't sufficient (the sub-CA could place a valid dNSName, and place a CN in the subject with another value). -- Erwann ABALEA - Mammifère : se dit d'un animal à squelette, poilu, qui donne du lait. Exemple : une noix de coco. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Blowfish output using openssl is too long
Hi, Hodie XIII Kal. Apr. MMIX, carlyo...@keycomm.co.uk scripsit: >I would suspect that an 8 byte IV has been appended/prefixed > >Carl > >On Thu 19/03/09 9:16 PM , Dick Hollenbeck d...@softplc.com sent: > > I am using on Ubuntu Hardy: > > $ openssl enc -bf-cbc -K 012221222F2D9E459E41001291222 \ > -iv 552279BBB1A9 -in file.raw -out file.enc > > and the output file is 8 bytes longer than the input file! > > The input file is 144 bytes long and the output file is 152 bytes > > Doing this in pycrypto, I do not get this result, the output file is the > same length. The added bytes are padding ones. Padding is necessary, since a block cipher operates on fixed-size blocks of bytes (here, 8 bytes or 64 bits). It is therefore quasi mandatory, since a generic decryption operation doesn't know in advance the size of the decrypted data, so the padding is also used to indicate how many bytes should be removed at the end. In your case, you're encrypting a 144 bytes long file, multiple of 8 bytes, so the padding consists of 8 bytes, each one being 0x08. Test the encryption of a 145 bytes long file, you'll also end with e 152 bytes encrypted file. There will be 7 padding bytes, each one being 0x07. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] key
Hi, Hodie XIV Kal. Iun. MMIX, naveen.bn scripsit: > I have a question ? can we have one public key and two private keys. You can (set d' to d+k.n with an integer k), but all the private keys will be equivalent. Everything you encrypt to the public key can be decrypted with either private key, and when verifying a signature, you won't be able to distinguish which private key was used to sign. In fact, it's exactly the same as copying the private key file without changing it. What are you trying to achieve? -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] key
Bonjour, Hodie XIV Kal. Iun. MMIX, naveen.bn scripsit: >Thank you for the reply. I was thinking that, if i ( A ) encrypt the >data with the public key from the certificate obtained from B, can the >intruder generate a private key using the public key from the same >certificate from B, which may lead to Man in Middle attack. >Please correct me if I am wrong . The intruder can *not* generate the private key from the public key. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] public key
Bonjour, Hodie XIV Kal. Iun. MMIX, naveen.bn scripsit: > I have used this command to obtain public key in hex but, how to get > the individual value of public key ( n,e). > openssl x509 -modulus -noout -inform PEM < > /home/certificates/MTA/MTA_DEVICE.cert.pem | sed s/Modulus=/0x/ > 0xC147647398B19BBC59CD2CEC49B8774E0025AC9161955CE5F9C6E2DCA8D026D04565F400C489379E48737DCDBCBD86F669B5796070259885D7603B54102E9D93FE8708E2BF46003BD53F671DF73CF9FA288D03BFA3E09E37F8D606F8F6AA5672DE2E386C818BFB93FF2111612EABA7663BD5745CB8FC27286A46EF498E4996388931FACEECDFDE7B283DF809B00784FA980E40FFE665FB0558C4C14BC93E58DF75444774644FB03EC90E7D42E794C1A0306FCAD3C2E1360E517E2B94ED0E61BAB4C4A90098AD33AC1F760CFDC58F1B238C04C68F3E893208E4771BC65D6A7B522014360BAD9BDC8AC88D88C492B6191D559B52F6A1E302181846BDC70BCF In fact, you asked for the modulus (n), and that's what you obtained. To get the entire public key, including the public exponent (e), use this: openssl x509 -pubkey -noout -in /home/certificates/MTA/MTA_DEVICE.cert.pem | openssl rsa -noout -text -pubin Then, do whatever is necessary to convert this output in something useful for you. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Possible bug in openssl?
Le 10/05/2012 11:39, Andreas Bießmann a écrit : [...] (one of the errournous boxes) ---8<--- abiessmann@azuregos % date Do 10. Mai 11:02:50 CEST 2012 abiessmann@azuregos % openssl version OpenSSL 1.0.1b 26 Apr 2012 abiessmann@azuregos % openssl s_client -connect banking.postbank.de:443 CONNECTED(0003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 320 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- --->8--- (the same for all boxes which use 1.0+ release) My questions: * can anyone confirm this behaviour (it seems other hosts are working with openssl 1.0+, but not the banking.postbank.de)? * can anyone give me a hint how to track this down? I happen to get the same behaviour behind our firewall when ECDHE-whatever is negociated as the ciphersuite. The FW drops the connection, resulting in this "errno=104" error. Try to limit the set of ciphersuites in your client. -- Erwann ABALEA - Lu sur alt.france : Peut-on installer Win 95 par dessus win 95 tout en gardant les differents données des logiciels fonctionnant auparavant sur wwin 95 ? -+- JMT in : Guide du neuneu d'Usenet - Neuneu persiste et signe -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Possible bug in openssl?
Le 10/05/2012 13:41, Andreas Bießmann a écrit : On Thu, May 10, 2012 at 12:38:00PM +0200, Erwann Abalea wrote: Le 10/05/2012 11:39, Andreas Bießmann a écrit : My questions: * can anyone confirm this behaviour (it seems other hosts are working with openssl 1.0+, but not the banking.postbank.de)? * can anyone give me a hint how to track this down? I happen to get the same behaviour behind our firewall when ECDHE-whatever is negociated as the ciphersuite. The FW drops the connection, resulting in this "errno=104" error. Try to limit the set of ciphersuites in your client. Ok so 'openssl s_client -connect banking.postbank.de:443 -cipher AES256-SHA' works with 1.0.1b. Thanks so far. After more tests on this host, it appears it suffers from the "0xff limit ClientHello" bug. Try adding a large SNI extension to make this message bigger, by adding the "-servername xx" argument to your command line, with a sufficiently large "xx" string. It will stop working. With this only cipher accepted, the "xx" has to be at least 192 bytes long to cause the server to fail. Your firewall is probably OK, your client is OK, the server is faulty. But it is nasty to limit cipher by host. So I could exclude all these ECDHE- stuff if these really causing the error. But I wonder if there is another solution. I see this behaviour with all tools using openssl 1.0.1. I found it first with python on my mac and asked myself why it works from time to time (python packaged by fink uses openssl-1.0.1, Apple's version uses openssl-0.9.8 ;). However that could be fixed by working around in my scripts but wget fails also and curl does, ... So I ask myself 'could there be a solution inside the library?'. The problem lies in the server, it's difficult to change the client's behaviour to correctly adapt to buggy servers. -- Erwann ABALEA - Quelqu'un peut me dire comment on fait pour creer un nouveaux groupe Usenet? A qui faut-il s'adresse? Cela coute il de quoi? -+- Moe in GNU - De quoi qu'est ce que ca coute-t-il combien ? -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How does openSSL handle the pathlen constraint?
Bonjour, Le 21/05/2012 14:10, Serge Emantayev a écrit : Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. This is conformant with X.509. The basicConstraints extension is not taken in consideration if present in a trust anchor (a root certificate is a trust anchor). Download X.509 recommendation, see chapter 10 (from memory), the validation algorithm is described. -- Erwann ABALEA - Ce ne sont que des propositions. Je ne veux pas les faire passer en force. Je pense que si mes idées doivent être reprises, elles ne doivent pas passer au vote, pour plusieurs raison : -+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How does openSSL handle the pathlen constraint?
Le 22/05/2012 10:57, Eisenacher, Patrick a écrit : -Original Message- From: Erwann Abalea Bonjour, Le 21/05/2012 14:10, Serge Emantayev a écrit : Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. This is conformant with X.509. The basicConstraints extension is not taken in consideration if present in a trust anchor (a root certificate is a trust anchor). Download X.509 recommendation, see chapter 10 (from memory), the validation algorithm is described. Actually, I find this hard to believe. The verifying party can deem any certificate as trusted and thereby making it its trust anchor. Nevertheless the verification process needs to take into account the extensions of the trust anchor and I don't see any reason to exclude basicConstraints. Can you please cite the relevant part of the validation algorithm that you reference? Taken from X.509, 2008/11 edition. But IIRC, the algorithm is the same since the 2000 edition, at least. - 10.5 Certificate processing Each certificate is then processed in turn, starting with the certificate signed using the input trusted public key. The last certificate is considered to be the end certificate; any other certificates are considered to be intermediate certificates. - Note that the first certificate taken into consideration is signed by the trust anchor, and not the trust anchor itself. - 10.5.1 Basic certificate checks The following checks are applied to a certificate. Self-signed certificates, if encountered in the path, are ignored. a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked. b) For an intermediate version 3 certificate, check that basicConstraints is present and that the cA component in the basicConstraints extension is TRUE. If the pathLenConstraint component is present, check that the current certification path does not violate that constraint (ignoring intermediate self-issued certificates) [...other basic steps...] - The same logic applies for other constraints extensions. Basically, from the trust anchor, you only take the public key, name, and validity dates. No extension at all. That's because a trust anchor doesn't need to be a certificate at all. -- Erwann ABALEA - OF> C'est quoi "godwin" ? un jeu ? une personne ? Une sorte de station-service : on accumule les points et on peut gagnerune gamelle. -+- PE in Guide du Neuneu d'Usenet - Le point sur les godwins -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] RE: Clarification regarding extension supported in OpenSSL certificates.
Yes to everything. As your question is not about the development of OpenSSL, but instead about its use, it should have been better in the openssl-users mailing list. Le 28/05/2012 15:43, Manas Ranjan Lenka a écrit : Hi, In addition to the below queries we have one more query in our mind. Please help us in answering to all those. 1.Does OpenSSL support SHA-256 hash Algorithm before signing certificate? Regards ManasL *From:*Manas Ranjan Lenka *Sent:* 28 May 2012 18:41 *To:* 'openssl-...@openssl.org' *Subject:* Clarification regarding extension supported in OpenSSL certificates. Hi, We are using openSSL command line tool for generating version 3 CA certificates as well IKE initiator/Responder certificates. We have the following doubts in our mind, Could you please clarify the same. 1.Does openSSL support version 3 certificate which is compliant to RFC 5280? 2.Does openSSL supports the following (Mandatory/Optional) extensions for CA Certificate as per section 6.1.4 of 3GPP spec TS 33.310. Mandatory: 1.key usage: keyCertSign and cRLSign. 2.basic constraints: CA=True, path length 0. Optional: 3.authority key identifier. 4.subject key identifier. Regards Manas Lenka -- Erwann ABALEA - "If it walks like a duck, and quacks like a duck, then it just may be a duck." - Reuther
Re: [openssl-users] Question regarding renegotiation in openssl-1.0.1
Why should it be different? -- Erwann ABALEA - gérontopropulsion prurigineuse: abus d'excès caractérisé par trop d'exagération (se fait quand on pousse mémé dans les orties) Le 13/06/2012 13:30, ankur dwivedi a écrit : Hi, I am observing that after doing a renegotiation, the new cipher is same as what was used while initial handshake. Is this a normal behavior ? -- Thanks Ankur Dwivedi
Re: [openssl-users] Bound check on RSA public exponent
The only limit check that I know is performed is if the modulus is strictly larger than OPENSSL_RSA_SMALL_MODULUS_BITS bits (3072 by default), then the public exponent must be less then or equal to OPENSSL_RSA_MAX_PUBEXP_BITS bits (64 by default). You can then have a 3072bits RSA key with a public exponent of any size. Or a 3073bits RSA key with a public exponent limited to 64bits. Other than for performance, I don't see any reason to limit the size of the public exponent. -- Erwann ABALEA Le 21/06/2012 16:41, Sukalp Bhople a écrit : Hello guys, I was looking into the (RSA) certificate verification in Openssl. I was wondering if Opensssl checks the size of the public exponent. Or what is the max public exponent accepted by server? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Bound check on RSA public exponent
Le 21/06/2012 18:18, Sukalp Bhople a écrit : Thank you very much for the helpful response, I searched for the terms you used in your reply and I found them in one of the function. This function is /static int RSA_eay_public_encrypt(int flen, const unsigned char *from,/ /unsigned char *to, RSA *rsa, int padding)/ / / You'll also find it in its "decrypt" counterpart. I was wondering, if there is any check on e while verifying certificate chains? (For instance, client certificate verification at server side) Why would you want a specific check on e? The check is done on the entire signature, with the entire key. Why e? For example, if the certificate presented by client has very large public exponent then what happen? How this e is stored? There should be some limit (data type BIGNUM) on it? Is this right? In a certificate, the element named subjectPublicKeyInfo is a SEQUENCE composed of 2 items, an algorithm identifier (also a SEQUENCE containing an OID and some parameters) and the subjectPublicKey. The latter is enclosed in a BITSTRING, and if it's an RSA key, it really contains a PKCS#1 encoded public key: a SEQUENCE containing 2 INTEGERS, modulus and public exponent. You can have any sized INTEGERS in here, and OpenSSL will parse them correctly. If the certificate has a very large public exponent, and a verification is performed, and the described limits are not overridden, there's no problem to expect. If you comment the limits in your own compiled library, there will still be no problem. You can get into a situation where a public RSA operation takes more time than a private one, if e is sufficiently large. But that's all. On Thu, Jun 21, 2012 at 5:14 PM, Erwann Abalea mailto:erwann.aba...@keynectis.com>> wrote: The only limit check that I know is performed is if the modulus is strictly larger than OPENSSL_RSA_SMALL_MODULUS_BITS bits (3072 by default), then the public exponent must be less then or equal to OPENSSL_RSA_MAX_PUBEXP_BITS bits (64 by default). You can then have a 3072bits RSA key with a public exponent of any size. Or a 3073bits RSA key with a public exponent limited to 64bits. Other than for performance, I don't see any reason to limit the size of the public exponent. Le 21/06/2012 16:41, Sukalp Bhople a écrit : Hello guys, I was looking into the (RSA) certificate verification in Openssl. I was wondering if Opensssl checks the size of the public exponent. Or what is the max public exponent accepted by server? -- Erwann ABALEA - ovopostégallinadoxie: doctrine qui soutient que la poule est apparue avant l'oeuf
Re: [openssl-users] X.509 certificate subject format
Le 02/07/2012 10:34, Johannes Bauer a écrit : I have a rather simple question regarding X.509 subjects that is not entirely clear to me and for which I cannot find the appropriate reference (pointers greatly appreciated). The trouble starts when trying to compare two subjects of *different* certificates for equality and becomes worse when certain fields are appearing more than once. To clarify, by "equal" I mean 'should behave in exactly the same way by all well-behaved implementations. Let's start easy. Consider the following subjects: subject1= /C=SE/O=FooBar/OU=BarFoo/CN=moo.koo.com subject2= /C=SE/OU=BarFoo/CN=moo.koo.com/O=FooBar Are these to be considered equal or not? Not equal. I.e.: Does the order of elements matter? Does the order matter when fields are duplicate, i.e. are: The order of elements in a SEQUENCE matters. The order of elements in a SET doesn't matter (read X.690 to get DER rules). Comparison rules for AttributeAndValue elements follow X.520 recommendation (you have to canonicalize them before comparison). subject1= /CN=foo/CN=bar subject2= /CN=bar/CN=foo equal? Not equal. If they are not equal, does the first one have a special meaning? For example, assume a webserver with a duplicate common name field. Are both names valid as the server name then? I.e. could I access a webserver with the certificate subject as stated above by DNS "foo" *and* "bar" or only by one of them? This is not specified by X.509. Browsers tend to accept such a certificate for an accessed FQDN equal to either "foo" or "bar". But you SHOULD place at most the first FQDN in a CN element in the subject, and other FQDN values in the subjectAlternativeName extension. One reason to ask for equality is that there maybe is a certificate X: issuerX = /O=myCA/OU=greatCA/CN=not subjectX= /CN=foo/CN=bar and it has a valid signature by a CA with the following subject: issuerX = /OU=greatCA/O=myCA/CN=not Is the certificate signature then valid? The signature may be cryptographically valid, but the names don't match, so "/OU=greatCA/O=myCA/CN=not" is not the issuer of "/CN=foo/CN=bar" (at least not in what you described, "/CN=foo/CN=bar" may have another certificate). -- Erwann ABALEA - Pas de panique, ça sera pire. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Padding used by the ca command
Bonjour, Le 02/07/2012 16:05, Mathias Tausig a écrit : Which padding method does openssl use, when I sign a certificate with the 'ca' command (using an RSA key)? RSA PKCS#1v1.5 Is there a way to change it? I don't think so. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Padding used by the ca command
Le 02/07/2012 19:38, Dr. Stephen Henson a écrit : On Mon, Jul 02, 2012, Erwann Abalea wrote: Le 02/07/2012 16:05, Mathias Tausig a écrit : Is there a way to change it? I don't think so. In openssl 1.0.1 and later you can use the -sigopt to change the signature format used. It currently supports PKCS#1 v1.5 and PSS. Thanks for the info. I kept the habit of looking in the source code because the help message isn't accurate, but the source I had here was a 1.0.0e. And "-sigopt" isn't mentioned in the help message ;) -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: create certificate request programmatically using OpenSSL API
GOST is not a block cipher, it's the acronym for "GOsudarstvennyi
STandard", which means "State Standard". It's not dedicated to cryptography.
Speaking of GOST standard is redundant, but clearer for non russian
locutors.
There's a block cipher (poorly) defined as a GOST standard, referenced
"GOST 28147-89". Attempts to be adopted as an ISO standard have failed.
The S-Box to use is not defined in the standard, whence 2 compliant
implementations can be non interoperable.
There's also a hash algorithm defined as a GOST standard, referenced
"GOST R 34.11-94" or "GOST 34.311-95", using GOST 28147-89 inside. "GOST
R 34.11-94" in itself is also useless because of the lack of S-Box
standard. The RFC 4357 defines 2 S-Boxes.
And finally there's a digital signature defined as a GOST standard,
referenced "GOST R 34.10-94" and superseded by "GOST R 34.10-2001"
(RFC5832), consider it similar to ECDSA. It uses "GOST R 34.11-94" to
hash data (just as {EC}DSA uses SHA{1,2*}).
--
Erwann ABALEA
Le 28/07/2012 21:31, Jeffrey Walton a écrit :
On Fri, Jul 27, 2012 at 9:00 AM, Abyss Lingvo wrote:
Hi all!
The last problem is how to create GOST key pair for certificate.
It is clear how to create RSA keys.
Sample is here : http://www.openssl.org/docs/crypto/EVP_PKEY_keygen.html
#include
#include
EVP_PKEY_CTX *ctx;
EVP_PKEY *pkey = NULL;
ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL);
if (!ctx)
/* Error occurred */
if (EVP_PKEY_keygen_init(ctx) <= 0)
/* Error */
if (EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048) <= 0)
/* Error */
/* Generate key */
if (EVP_PKEY_keygen(ctx, &pkey) <= 0)
/* Error */
Unfortunately there is no EVP_PKEY_GOST constant and I can't create EVP_PKEY
containing GOST key pair.
Does anybody know how to create GOST key pair?
GOST is a block cipher. It uses a symmetric key, not public/private keys.
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Weird not-so-self-signed certificate
Bonjour, The given certificate is correctly self-signed, you can manually check it by extracting the signature block and playing with "openssl rsautl ...", "dd ... | openssl dgst -sha1", etc. It fails the validation path check probably because it's not declared as a CA. There's some ongoing work on IETF about DANE certificates and clarifications on RFC5280 about self-signed EE certificates. The presented certificate is certainly such a DANE one. -- Erwann ABALEA - pastacircopyge: quelqu'un qui a vraiment beaucoup de chance Le 06/08/2012 13:04, Johannes Bauer a écrit : Hi list, I'm quite puzzled and hope somebody can help me. I'm handling a large number of certificates and for generating testcases for the software I employ, I wrote a small script that downloaded web server certificates en bulk and then processed them, to check for irregularities. My software barfed on a certain certificate, which is this one: -BEGIN CERTIFICATE- MIIC8TCCAdmgAwIBAgIQNmL4pIUXFpRBUK7QhJR/JjANBgkqhkiG9w0BAQUFADAg MR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFHSjgwHhcNMTAxMjIzMjAzOTU0 WhcNMjAxMjIwMjAzOTU0WjAgMR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFH SjgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD6CNzdS+lWquEQndmY R1XY6cEqeMSB6YVSxXFAARRsdLQceCIpZbD5CijYklx874gOokTwSzZ7EJ6QSPUL jItM5PRlkeh0twrVEU5UTeqybAnVEciL5oVy6EPm4niYweAJrf5QCtPcORtt2Kjs xYAX2Ltl7mjvi+QM+XwDX0LKWyIjpYTZXB/5XRnpzUuBw3pDx+z4fWk8SFqN4Ptb /7fZSoxI6VeuTvrgS4aMyjsPylPnpXVAFYOcxketS0D1F9m0z5t3eD3hXesgbCHS svy0gACF3qvarJiE6MVDaJ/tlX408G9V3gEHpCCrk+yL5FiT/dtr7tNlWMt+o9D4 5/kNAgMBAAGjJzAlMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA4GA1UdDwQHAwUAsAAA ADANBgkqhkiG9w0BAQUFAAOCAQEAYvuUspk2lHiP3IM4maY2DOH0UfSsldyqOICP ue3xmqNnkhN7QBe8GIcsKt3fiozC7L+zcxdIY6L7WgGx1+aK8f3AKl/FojPegMhC WsgNy5WsR+jLUduclZDGf4qXxo9Vs1qXeP4qYZOa1rtqiBfFaQsxs4+XyFHdaB8N HzviKd8NSeCn+ZfUTKYlErUAL+qtLaQQTqVvBVnwR9yT74izZ48f0mX8zHYMFJIk mokioFqzl2ZVF98JBLSy6sNTZfO+eg98g3uDVRwq9JyvsWp1OJ94BvoXFZX7ETDM Z53Hp5s3YUNRptlIvzre/foKg4MZB8BNUsEUdgaGOeoXho7jDA== -END CERTIFICATE- It's seemingly self-signed, but then again -- not. When I call openssl: $ openssl verify -CApath /dev/null -CAfile weird.crt weird.crt weird.crt: /CN=WMSvc-WIN-EEBHLC81GJ8 error 20 at 0 depth lookup:unable to get local issuer certificate Interestingly the lookup fails at depth 0 (!). If a parent certificate were missing, I'd expect a lookup fail at depth 1. When I create a self-signed certificate: $ openssl req -new -x509 -nodes -out foobar.crt And check it then: $ openssl verify -CApath /dev/null -CAfile foobar.crt foobar.crt foobar.crt: OK I'm puzzled and before jumping to conclusions wanted to ask you first what you think of that. Best regards, Johannes __ 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: [openssl-users] ECDSA sign/verify input data size
Bonjour, Which part of the examples did you mimic? 32 bytes is the length of a SHA256, it's also the max message length of a 256bits ECDSA key. Whence, I assume you're doing straight ECDSA_do_sign() without hashing and padding the message. -- Erwann ABALEA - paléogallicisme: style "vieille France" Le 06/08/2012 13:11, Mohammad Khodaei a écrit : Hello, I have used ECDSA APIs to sign and verify some data. The sample example I have used to do so is like this: http://old.nabble.com/Bug-in-ECDSA_do_sign--td1071562.html Now, the problem is that it seems there is some kind of limitations on the input data size. Whenever I want to verify the signature on a string, it calculates the signature verification only on the first 32 characters and it skips the rest of the string. It is a bit strange for me since I feed the function with correct length. Any idea where is my mistakes? Thanks a lot __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] ECDSA sign/verify input data size
Use the EVP_* interface for high-level functions. Use ECDSA_do_sign() or other low-level functions if you're absolutely sure about what you're doing. -- Erwann ABALEA Le 06/08/2012 14:31, Mohammad khodaei a écrit : Yes, it's correct. Now I try to feed the ECDSA_do_sign with the output buffer of SHA256. Based on my security knowledge, I thought that the signing algorithms perform hashing internally, while in this case it is not true. Thanks for the response. ---- *From:* Erwann Abalea *To:* openssl-users@openssl.org *Cc:* Mohammad Khodaei *Sent:* Monday, August 6, 2012 2:14 PM *Subject:* Re: [openssl-users] ECDSA sign/verify input data size Bonjour, Which part of the examples did you mimic? 32 bytes is the length of a SHA256, it's also the max message length of a 256bits ECDSA key. Whence, I assume you're doing straight ECDSA_do_sign() without hashing and padding the message. -- Erwann ABALEA - paléogallicisme: style "vieille France" Le 06/08/2012 13:11, Mohammad Khodaei a écrit : > Hello, > > I have used ECDSA APIs to sign and verify some data. The sample example I have used to do so is like this: > > http://old.nabble.com/Bug-in-ECDSA_do_sign--td1071562.html > > Now, the problem is that it seems there is some kind of limitations on the input data size. Whenever I want to verify the signature on a string, it calculates the signature verification only on the first 32 characters and it skips the rest of the string. It is a bit strange for me since I feed the function with correct length. > > Any idea where is my mistakes? > > Thanks a lot __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org <mailto:openssl-users@openssl.org> Automated List Manager majord...@openssl.org <mailto:majord...@openssl.org>
Re: [openssl-users] OpenSSL OCSP
Bonjour, Answers inline. -- Erwann ABALEA Le 14/08/2012 19:03, adrien pisarz a écrit : Hi, I have several questions about the ocsp functionnality. I read many articles before asking those questions and unfortunetaly I still don't have the answers. Maybe you can help me. Fist of all, here is my ocsp configuration : openssl ocsp -index index_prod.txt -CAfile OpCA.pem -rsigner ocsp.crt -rkey ocsp.key -port 3456 -text -out /home/userocsp/ocsp_responder.log The file index is populated by a self-made script, the ocsp.crt (resp. key) is a certificate (resp. key) which contains the ocsp signature extensions the OpCA.pem contains the subAC certificate Here are my questions : 1. Why the ocsp client work only if the -VAFile is set and otherwise I got a signature error ? Is there a way to solve this issue ? Maybe because the responder is not one of: - the CA that signed the certificate you're requesting the status on - a designated responder directly signed by the CA that signed the certificate you're requesting the status on Reread RFC2560. If you're instanciating the third possible responder type (trusted responder whose public key is trusted by the requester), then you obviously need to inform the client/requester. You didn't provide elements on who signed who, so that's just a guess. 2. If I wan manage several subAC should I open a port foreach subCA ? With the command-line tool, yes. If you need to have more CAs, then you could probably try something more suited than the command-line tools. The command-line tool also doesn't respond to GET requests, only POST ones. 3. Why the ocsp responder requires that all the certificates (even the valide's one) must be present in the index.txt in order to provide a correct answer ? I was expected that openssl will check the certificate signature and if the serial is not present in the index.txt, it will answer good and not unknow. Design choice. You're giving the responder a database, so it supposed to know *all* the certificates. OCSP can be based on CRLs (black-list), but that's not implemented by the tool. If that's what you want, you'll have to write your own. 4. As said, the openssl responder is working but a IHS server is not abble to validate his answer and I got those errors : [...] Does anyone know how to configure an IHS with an openssl ocsp responder ? You may ask your provider for this, not OpenSSL.
Re: [openssl-users] OpenSSL OCSP
Le 16/08/2012 18:38, adrien pisarz a écrit : Ps: does anyone know why the engine option is not available with ocsp and the private key must be in a file instead of store securely in a HSM ? As said by Dr Henson, this is only a testing tool, not a production service. If you need a production-grade system, you'll have to write your own using the API. -- Erwann ABALEA
Re: [openssl-users] converting text to pem
Bonjour, Le 17/08/2012 09:33, kiran Palli a écrit : Hi, I generated an rsa 2048 key-pair with these commands: openssl.exe genrsa -F4 -out key.pem 2048 openssl.exe rsa -text -in key.pem > key.txt Now I lost the key.pem file and also lost the key.txt in its original format. That's sad. 2 files lost at the same time? And you weren't taught to take care of these? They weren't important, were they? Why don't you just throw that key away and pick a new one? But I have private exponent and public exponent from the text file. Those were enough for my tool suite to sign a binary file and then verify. Now I need to test something with openSSL signing, but how do I recover the private key in .pem format (key.pem)? Looks like homework. Did you ask Google? This is the left over portion of key.txt(example, but a valid key-pair): Private-Key: (2048 bit) modulus: |00:f3:5a:8f:46:08:11:d8:f7:65:eb:26:8f:e6:fe: [...] d2:61 | publicExponent: 65537 (0x10001) privateExponent: |73:e4:bd:f4:e1:24:f6:ca:23:7c:90:99:d9:ad:9c: [...] 11| Using bc you can quickly get p, q, dp and dq. qinv is harder to get, but it's possible. -- Erwann ABALEA
Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Bonjour, Le 24/09/2012 21:03, Jakob Bohm a écrit : Does that work with any other serious X.509 validation toolkit? It should. When trying to build a valid certification path, all possibilities have to be tested until one of them succeeds. If a CA gives a good signature, but fails for whatever reason (a non respected constraint, a revoked state, or an expired certificate), then the considered certificate chain is invalid, and the next has to be tested. To make this work (assuming the old root CA cert has not yet expired), the validation code will need to actually verify the End Entity certificate against both public keys, which effectively reduces the algorithm security by allowing twice as many bit strings to be accepted as valid. An EE can be valid under different certificate chains, without reducing the security of anything. Think about cross-certifications. As for trust anchor update scenarios, I know of 3 different scenarios that should be accepted by any good X.509 validation algorithm: 1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. This needs a manual update of the trust store, as you're introducing a new certificate object not linked to anything. Following X509 rules, you can also change the key. Following RFC5280 ones, you can't (in fact, you can, but it won't be the root of the same PKI). 2. Changing the CA key when the old key has *not* been compromised. Here the CA generates a new key and issues two certificates for it: A. A self-signed new root with a serial number or other variation in one of the subject name components. This is a change in the name of the CA, whence it's a completely different CA. B. A certificate for the new key and the same subject and (optional) SubjectKeyIdentifier as A, but issued by the old root certificate identity and key. That's a self-issued certificate, it's OK until the old CA certificate is not expired. Well described in X.509. Manual update of the trust anchor is still necessary if you want the validation to pass the expiration date of the old CA cert. 3. Setting up the CA to have keys for more than one algorithm (such as RSA 1024 with SHA1 and RSA 4096 with SHA256). In this case, the certificate validation could SHOULD (but might not) match issued end entity certificates to the trust anchor by also comparing signatureAlgorithm in the issued certificate against subjectPublicKeyInfo.algorithm in the candidate issuer cert from the store. The issued certificate will have "sha1withRSA" or "sha256withRSA" in its signatureAlgorithm, not "sha1withRSA1024" or "sha256withRSA4096". A "SHA256" certificate (or however you call it) can still produce "sha1withRSA" signatures. The other way is also possible, of course. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Bonjour, Le 25/09/2012 14:16, Jakob Bohm a écrit : On 9/25/2012 11:11 AM, Erwann Abalea wrote: Le 24/09/2012 21:03, Jakob Bohm a écrit : > Does that work with any other serious X.509 validation toolkit? It should. And in fact, OpenSSL works correctly, at least versions 1.0.1 (Ubuntu), and 1.1.0 (from sources). The 1.0.1 version displays a warning if it finds the expired certificate first, but the verification goes on with the next certificates, and it finally gives an OK result. That can be checked either by removing the nonexpired certificate from the CAfile or by changing to the CApath mode and using strace to see OpenSSL opens the second CA certificate (named 415660c1.1). When trying to build a valid certification path, all possibilities have to be tested until one of them succeeds. If a CA gives a good signature, but fails for whatever reason (a non respected constraint, a revoked state, or an expired certificate), then the considered certificate chain is invalid, and the next has to be tested. Read carefully, I said that if the only way to pick the right candidate is to validate the signature against 2 same-algorithm public keys, then the security of the signature validation is reduced by up to log2(keycount) bits. ?? Could you elaborate on this? Anything that can be filtered out without signature checking (such as different algorithms, different key identifies, different key lengths etc.) does not cause that problem. And is OK security wise, but may not be implemented by all (otherwise compliant) X.509 implementations. > To make this work (assuming the old root CA cert has not yet expired), > the validation code will need to actually verify the End Entity > certificate against both public keys, which effectively reduces the > algorithm security by allowing twice as many bit strings to be > accepted as valid. An EE can be valid under different certificate chains, without reducing the security of anything. Think about cross-certifications. Cross-certifications involve different distinguished names for signature chain building, these can all be verified by building the trusted chain before validating the signatures. You're right. The cross-certified entity will have different certificates, each one with a distinct issuer name. > As for trust anchor update scenarios, I know of 3 different scenarios > that should be accepted by any good X.509 validation algorithm: > > 1. Changing expiry or other attributes while keeping the key. > Here the CA issues a new self-signed certificate with updated > attributes but unchanged key. > 2. Changing the CA key when the old key has *not* been compromised. > Here the CA generates a new key and issues two certificates for it: > >A. A self-signed new root with a serial number or other variation > in one of the subject name components. This is a change in the name of the CA, whence it's a completely different CA. Yes, but it will still have a sufficiently close name to retain any reputation based human trust. What about the DigiCert (Malaysia) against DigiCert, Inc (US) not so old problem? >B. A certificate for the new key and the same subject and (optional) > SubjectKeyIdentifier as A, but issued by the old root certificate > identity and key. That's a self-issued certificate, it's OK until the old CA certificate is not expired. Well described in X.509. Manual update of the trust anchor is still necessary if you want the validation to pass the expiration date of the old CA cert. Actually, this is a cross-certificate from the old CA to the new CA. as you said, well described in the literature. Again, I misread. The case you're describing is really a cross-certificate. So there's one more possibility: the CA changes its key, keeps its name (so it's the same CA), and issues 2 certificates. First one is a self-signed one with its brand new key. Second one is a self-issued one, signed by the previous key. Both this case and the previous one are used by several countries for CSCA certificates (for passports). Some of the discussions on this thread seems to indicate that when both the A and B certificate are available, OpenSSL sometimes may fail to stop when it hits the new (A) CA in the trust store because it does not distinguish between its trust store and its collection of cached/preloaded intermediary certificates (unlike Windows, which has seperate stores for those two categories). What I understand from the OP seems to be different from this paragraph. I grabed the old 1996-2004 VeriSign C3 root certificate, and its renewed version 1996-2028 (same key, same name). That's your scenario 1. The Thawte CA certificate doesn't have any authorityKeyIdentifier extension, and OpenSSL correctly tests each possible certificate, filtered by their subject name, until the validation is OK.
Re: [openssl-users] Error while parsing x509 certificate using ecdsa-with-SHA256
Bonsoir, Your public key parameter field is set to NULL. It must either be an OID to name the curve, or explicit parameters. -- Erwann ABALEA Le 26/09/2012 14:17, Naveen Gopala Reddy a écrit : Hi, I am using openssl version 1.0.1c to parse the attached certificate(test.pem) using the below command. $ openssl x509 -in test.pem -text However, I get the following error + Unable to load Public Key 3077577480:error:100DC08E:elliptic curve routines:ECKEY_TYPE2PARAM:decode error:ec_ameth.c:178: 3077577480:error:100D7010:elliptic curve routines:ECKEY_PUB_DECODE:EC lib:ec_ameth.c:206: 3077577480:error:0B07707D:x509 certificate routines:X509_PUBKEY_get:public key decode error:x_pubkey.c:164: + Could you please help me debug the same. Thanks and regards, Naveen __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Le 25/09/2012 18:45, Jakob Bohm a écrit :
On 9/25/2012 6:12 PM, Erwann Abalea wrote:
Le 25/09/2012 14:16, Jakob Bohm a écrit :
> On 9/25/2012 11:11 AM, Erwann Abalea wrote:
[...]
Any signature algorithm works by dividing the universe of N bit strings
into those that are validsignatures for the object and those that are
not. For most algorithms the valid subset is exactly one of the 2**N
bit strings, for some ECC variants it is two of them, for DSA it is
2**(N/2) of them. [...]
I'll have to re-read this in a quiet environment, with my HAC kept
close. Thanks.
[...]
So there's one more possibility: the CA changes its key, keeps its name
(so it's the same CA), and issues 2 certificates. First one is a
self-signed one with its brand new key. Second one is a self-issued one,
signed by the previous key.
Both this case and the previous one are used by several countries for
CSCA certificates (for passports).
So you say they have an intermediary certificate where
Issuer DN==Subject DN,
but the Issuer keyis not the key in the cert itself. Very weird, unless
there are appropriate key identifiers in thecertificates.
That's right. And that's precisely a self-issued certificate, considered
differently on the validation algorithm. For example, such a certificate
doesn't count for the pathLen constraints.
{subject,authority}KeyIdentifier extensions are not mandatory.
Consider a root CA with a self-signed certificate, with only
digitalSignature set in its keyUsage extension. This CA can then
self-issue another certificate with the cRLSign bit set. That's
different from a CA with 2 self-signed certificates, each one for one
usage. The former is valid for RFC5280 while the latter isn't, both are
valid for X.509.
[hours later]
Another scenario has been used in real world: have the root certificate
contain the hash of the public key of the next root (etc), the subject
name doesn't change. That was used for SET (shortly, I admit), as all CA
certificates were renewed every year. Some kind of forward chaining.
> Some of the discussions on this thread seems to indicate that when
> both the
> A and B certificate are available, OpenSSL sometimes may fail to stop
> when
> it hits the new (A) CA in the trust store because it does not
> distinguish between
> its trust store and its collection of cached/preloaded intermediary
> certificates
> (unlike Windows, which has seperate stores for those two categories).
What I understand from the OP seems to be different from this paragraph.
I grabed the old 1996-2004 VeriSign C3 root certificate, and its renewed
version 1996-2028 (same key, same name). That's your scenario 1.
The Thawte CA certificate doesn't have any authorityKeyIdentifier
extension, and OpenSSL correctly tests each possible certificate,
filtered by their subject name, until the validation is OK.
I assume the Thawte certificate you mention is not the same as the
VeriSign certificate (they havebeen the same company for a long time
now).
The OP talked about www.google.com, I connected and got a 1024bits
intermediate Thawte certificate from 2004, signed by VeriSign C3.
--
Erwann ABALEA
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] UUID OID and certificatePolicies routines:a2d_ASN1_OBJECT:invalid digit
__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
[openssl-users] UUID OID and certificatePolicies routines:a2d_ASN1_OBJECT:invalid digit
Strange, my previous answer was sent empty, and every try results in an empty mail stored in my postponed folder... Anyway. Use decimal numbers for an OID. Yours will be 2.25.266774424501754920443129542379924997403 And for your policyIdentifier, it should be easier to read if expressed as "company_root_oid.2.5.29.32.1". -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] UUID OID and certificatePolicies routines:a2d_ASN1_OBJECT:invalid digit
Bonjour,
Le 28/09/2012 16:29, Valentin Bud a écrit :
On Fri, Sep 28, 2012 at 02:53:35PM +0200, Erwann Abalea wrote:
Strange, my previous answer was sent empty, and every try results in
an empty mail stored in my postponed folder...
Anyway.
Use decimal numbers for an OID.
Yours will be 2.25.266774424501754920443129542379924997403
How did you transform the number from hex to decimal? I have been
looking to do this for an hour now to no avail.
Thanks for giving me the number.
(echo "ibase=16"; echo "c8b2e2a0094b11e2936a0002a5d5c51b" | tr 'a-f'
'A-F') | bc -l
Still it doesn't work. Another error now. But first, the changes I have
done are as follows:
openssl.cnf
===
# This is at the beginning of the file
company_root_oid = 2.25.266774424501754920443129542379924997403
[ company_ca_policy ]
policyIdentifier = company_root_oid.2.5.29.32.1
My fault here.
I'd use:
-
oid_section = new_oids
[ new_oids ]
company_root_oid = 2.25.266774424501754920443129542379924997403
acceptable_cp = ${company_root_oid}.2.5.29.32.1
[ req ]
distinguished_name = mydn
[ mydn ]
[ company_v3_ca ]
certificatePolicies = @mypolicy
[ mypolicy ]
policyIdentifier = acceptable_cp
-
Some pieces are still missing there, but with the command line you used
below, with the addition of a "-subj '/C=XX/O=Company/CN=Company Root'",
you'll have a certificate.
Since you're new to PKI, I don't think you've already created and
populated the .2.5.29.32 branch of your OID arc, and I'm guessing you
took this 2.5.29.32 from the RFC. If yes, forget about it and organize
your OID arc the way you want. For example have a .1 for all your
certificate policies, and dedicate one for the CP you want to declare here:
allcompanyCP = ${company_root_oid}.1
CPforwebservers = ${allcompanyCP}.1
and use CPforwebservers as the declared policyIdentifier.
[ company_v3_ca ]
certificatePolicies = ia5org,@company_ca_policy
===
The error is the following:
wiz:CA/ (master) $ openssl req -new -x509 -days 3650 -extensions
company_v3_ca -keyout private/company.ca.key -out certs/company.ca.pem -config
openssl.cnf
Error Loading extension section v3_ca
6198:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too
large:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/asn1/a_object.c:109:
6198:error:2208306E:X509 V3 routines:POLICY_SECTION:invalid object
identifier:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/x509v3/v3_cpols.c:211:section:company_ca_policy,name:policyIdentifier,value:company_root_oid.2.5.29.32.1
6198:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in
extension:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/x509v3/v3_conf.c:93:name=certificatePolicies,
value=ia5org,company_ca_policy
The OpenSSL version, if it matters is:
wiz:CA/ (master) $ openssl version
OpenSSL 0.9.8r 8 Feb 2011
I don't know what I am doing wrong. PKI is a vast topic with a lot of
things to grasp. I have to take it slow.
I do have one question though. In the link that Ryan Hurst suggested the
policyIdentifier is left out.
What is the difference between the two? Would I be RFC compliant if I
would use a policyIdentifier or none at all or it doesn't matter?
For a root certificate, the certificatePolicies extension is generally
of no use. Some entities ask for this extension to be absent.
The normative validation algorithm doesn't take into account any
extension from the trust anchor (your root is a trust anchor), but some
implementations could eventually look at these and set parameters (used
by the algorithm). You may want to dig into RFC5280 section 6 or X.509
section 10 if you want to know more about it. Beware, it's insane.
I have read somewhere that some applications cannot parse UUIDs. If
using a certificate policy without a policyIdentifier would keep me RFC
complaint I would choose to do that. I don't want to get in trouble with
applications.
This has nothing to do with UUIDs here, as the relying party won't have
to parse this OID, it doesn't need to have any structure. The UUID is
used here to have a unique OID arc.
Acquiring an OID for the company is not possible, at least for now. I
guess that would be the most elegant solution.
It's always possible to get a private OID in the 1.3.6.1.4.1 branch.
Just send an email, and you'll have one.
Depending on your country, you may even already have one, based on your
company's unique registration number.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: Reference material on how to do certificate validation with OpenSSL
Where's the failure here?
hostname_matched is set to HOSTNAME_VALIDATION_ERR at initialization,
and in case of a NULL hostname or certificate it is returned by the
function, unmodified.
--
Erwann ABALEA
Le 27/10/2012 21:00, Jeffrey Walton a écrit :
On Sat, Oct 27, 2012 at 11:00 AM, Alban D. wrote:
Hi everyone,
iSEC Partners just released a paper that provides detailed guidelines
and sample code on how to properly do certificate validation with
OpenSSL:
http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html
It is not trivial and so I thought this reference material could be
useful to people on this mailing list.
] int validate_hostname(char *hostname, X509 *server_cert) {
] int hostname_matched = HOSTNAME_VALIDATION_ERR;
] if((hostname == NULL) || (server_cert == NULL))
] goto error;
] ...
] error:
] return hostname_matched;
] }
You failed open rather than closed. Its not a good choice of
strategies for high integrity software.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Reference material on how to do certificate validation with OpenSSL
Bonjour, In the 4.2 paragraph, talking about revocation, you explicitely write that your code examples don't check for revocation. Depending on your target audience, this might not be a wise choice. In the same part, you're referring to a post by Ben Laurie about how hard it is to detect revoked certificates, and thus how "useless" it is to revoke a certificate, because applications don't check for revocation, or do it with a soft-fail behavior. That's something public CAs want to be changed, and the lack of revocation check in your examples won't help. -- Erwann ABALEA Le 27/10/2012 17:00, Alban D. a écrit : Hi everyone, iSEC Partners just released a paper that provides detailed guidelines and sample code on how to properly do certificate validation with OpenSSL: http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html It is not trivial and so I thought this reference material could be useful to people on this mailing list. Thanks, Alban D. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
