Re: APIs forbidden in FIPS mode
Dr. Stephen Henson steve-mcmkbn63+blafugrpc6...@public.gmane.org
writes:
[...]
RSA_private_decrypt is fine [...]
Is it? It begins with discouraging-looking code:
int RSA_private_decrypt(int flen, const unsigned char *from, unsigned char
*to,
RSA *rsa, int padding)
{
#ifdef OPENSSL_FIPS
if (FIPS_mode() !(rsa-meth-flags RSA_FLAG_FIPS_METHOD)
!(rsa-flags RSA_FLAG_NON_FIPS_ALLOW))
{
RSAerr(RSA_F_RSA_PRIVATE_DECRYPT, RSA_R_NON_FIPS_RSA_METHOD);
return -1;
}
#endif
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
PKCS12_parse produces ca stack in reverse order
If one naively uses PKCS12_parse to extract key, certificate, and certificate chain, and then iterates through the STACK_OF(X509) calling SSL_CTX_add_extra_chain_cert (starting at sk_X509_value(ca, 0)) then the chain will be in the opposite order to what's in the PKCS#12 file. That seems consistent with what the code in crypto/pkcs12/p12_kiss.c is saying: having constructed ocerts from the file, it iterates with a loop while ((x = sk_X509_pop(ocerts))) doing if (!sk_X509_push(*ca, x)) So (IIUC) the order's exactly reversed. Is that behaviour a bug or a feature? (Given that it's presumably always been that way, I guess it's a feature?) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: APIs forbidden in FIPS mode
Dr. Stephen Henson steve-mcmkbn63+blafugrpc6...@public.gmane.org writes: [...] Validated RSA_METHOD structures set RSA_FLAG_FIPS_METHOD, so that will work with the FIPS module. That code is there so you can't accidentally use an unvalidated method (e.g. from an ENGINE) in FIPS mode but if you are sure it is acceptable it can be overridden by setting RSA_FLAG_NON_FIPS_ALLOW in the key. Ah, right. Like an idiot, I was just looking through openssl and binary openssl-fips files, which of course don't mention RSA_FLAG_FIPS_METHOD. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Apply signature to X509 certificate
Cristian Thiago Moecke contato-pbw9x2wndctn3hn+mpyg4faujnlxr...@public.gmane.org writes: You have two ways to follow. 1) To use an HSM to sign, the official way to do it is to use an openssl engine. If your HSM does not provide an openssl engine, it probably does provide a PKCS#11 module, and you can use the pkcs11 engine to load it and use it. As a slight simplification, you can create an RSA with your own RSA_ENGINE that uses your HSM. (You only need to provide signing, so this is relatively straightforward.) Then use that in the regular signing operation. (Similarly for DSA, EC_KEY, obviously, though IIRC the EC code is still in a private header.) [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CRL checking failing in 1.0.1
Bin Lu blu-3r7miqu9kmnr7s880jo...@public.gmane.org writes:
[...]
if (dcrl)
{
ok = ctx-check_crl(ctx, dcrl);
if (!ok)
goto err;
ok = ctx-cert_crl(ctx, dcrl, x); ç this does not
run since dcrl is NULL
if (!ok)
goto err;
}
else
ok = 1; ç so always return success
and the next bit of code is:
/* Don't look in full CRL if delta reason is removefromCRL */
if (ok != 2)
{
ok = ctx-cert_crl(ctx, crl, x);
if (!ok)
goto err;
}
so ctx-cert_crl is being called.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Compiling static vs. dynamic and building a universal binary
Geoff Thorpe [EMAIL PROTECTED] writes: [...] Has this ever been (in recent history) an issue within a given release branch? Ie. has 0.9.8(n+1) ever broken apps that were running ok against 0.9.8n? 0.9.8x is of course not backwards compatible with 0.9.7y, and 0.9.9 will not be backwards compatible with 0.9.8 either. But that's why (reputable) distros allow these branches to coexist and be upgraded independently. I suspect an application using PKCS12_create and passing a non-NULL name will segfault on 0.9.8h. (I confess I've not actually tried that---I've only tried with an application built against 0.9.8h.) However, I guess (presuming the problem really exists, and I didn't mess up somehow) that's more a bug than a binary incompatibility. 0.9.8g (IIRC) broke source compatibility in the sense that at least some C++ compilers don't accept some of the headers. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Compiling static vs. dynamic and building a universal binary
Geoff Thorpe [EMAIL PROTECTED] writes: [...] But in fact, the original question was about binary compatibility Sure, and I've no reason to believe binary compatibility has been broken in 0.9.8. (Though it's something I've never really cared about.) [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: multiple nameConstraints
Stephen Lewis step...@commsguy.eu writes: [...] - 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 ? I don't think that's possible (independent of what's expressible in openssl.cnf). See the description in RFC 5280, http://tools.ietf.org/html/rfc5280#page-42. The intent seems clearly subtree-based, not any more general pattern-matching, so CN=*.mydomain.com and similar hacks don't seem cleanly controllable by this. I'd guess the best thing to do would be to somehow require the use of the proper subjectAltName form---I don't know of a generally accepted way to do that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Add extra informations to certs
li...@kaiser.cx writes: Hi, On Tue, Mar 31, 2009 at 05:29:15PM +0200, Dirk Reske wrote: We need to put some extra informations (simple strings) into the certificates (e.g. year of birth, ...). I have looked around the internet, but don't really find any usefull stuff. define a private extension. See RFC3280, section 4.2 for an introduction to extensions. Presumably the standard subject directory attributes extension might be appropriate. http://tools.ietf.org/html/rfc5280#section-4.2.1.8 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: s_client output
Joe Friedeggs friedegg...@hotmail.com writes: I'm pretty much a noob when it comes to SSL, so any help would be greatly appreciated. I just installed Openldap running TLS with self signed certs. Everything *seems* to be working fine (LDAP logs show TLS encryption), but when I run the s_client from the LDAP (Linux) client, I only see ONLY: I would guess that your server (and client) are using STARTTLS (so they start in LDAP and use an LDAP protocol command to switch to TLS). s_client (as of 0.9.8something) doesn't know about LDAP STARTTLS (and you didn't specify -starttls anyway). wireshark ought to show you what's happening (presuming you can get that working, of course). [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Callback suggestion for unsupported cert extensions
Victor B. Wagner vi...@cryptocom.ru writes: [...] This is about unexpected values in KNOWN extension. Not about totally new extension with new OID. I think you're misreading it---I think it's talking about unexpected extensions. In any case I think the language in RFC 5280 makes it clearer (and we should assume that this was the intent of 3280): A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: trying to replicate ECC signing with openssl
Mike Frysinger vap...@gentoo.org writes: [...] ive been trying to figure out exactly how to invoke openssl to get the equivalent behavior. It's beyond me, I'm afraid. But a couple of things do suggest themselves... [...] i'm creating the parameters file with: openssl ecparam -name sect163k1 -rand randfile -param_enc explicit -text I think that's the wrong thing to be trying to do. I think you've been given the private key, so you just need to somehow combine the bits you've been given into the form that OpenSSL wants. Probably (and this is the bit that's beyond me) you need to produce a group and a public key (both of which are public parts of the key), and presumably these are the first numbers you gave. Then, you need to use the private key and the random number to form the ECDSA signature of the file. ECDSA with SHA1 requires 160 bits of random data, which is exactly what you've been given so that matches up. (I don't see a way to provide the random number to any of the OpenSSL functions, so perhaps some hacking will be needed for that part.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: RSA algorithm with big endian environment
Alessandro Borga al...@libero.it writes: I must use RSA encrypt/decprypt functions in a target using Arm cpu. Other rsa source code doesn’t work right because target environment use big endian memory allocation for int and long Really? SPARC (32bit) is big-endian, and really quite common (less though than it used to be, admittedly). Can openSLL crypto lib work with big endian? OpenSSL works fine on 32 bit SPARC. (As far as I'm aware, anyway. I don't recall seeing any problems.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Newbie question on EVP API
Alexey Luchko l...@ank-sia.com writes: I'm new to openssl. I've got two questions on EVP API: 1. What do EVP_EncryptInit_ex and EVP_CipherInit_ex differ with? When should I use encrypt/decrypt and when cipher? If you look at the source, EVP_EncryptInit_ex/EVP_DecryptInit_ex are just trivial wrappers around EVP_CipherInit_ex. So use whichever seems to make more sense to you. 2. Where can I read about cipher modes? There are several modes for each cipher on http://openssl.org/docs/crypto/EVP_EncryptInit.html#CIPHER%20LISTING They differ with suffix like _cbc, _ecb, _cfb, _ofb and etc. What are meanings of these suffixes and use-cases? They're standard chaining modes. wikipedia has a reasonable description of them. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
CFB change (was Re: OpenSSL version 0.9.8m release)
With 0.9.8m I'm getting some failures to read PEM files (and do some other thnigs, I think) that 0.9.8l is happy with. The PEM files are created by BouncyCastle, I think (though I imagine 0.9.8l could be persuaded to write similarly failing files). they begin something like: -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CFB,9ab9883444955f24fc4d9ac26efa955d They seem to be caused by this change, so what's the story behind it? i.e., how worried should I be that software's currently writing files that are rejected by the new code in OpenSSL? Author: steve steve Date: Mon Feb 15 19:40:45 2010 + The block length for CFB mode was incorrectly coded as 1 all the time. It should be the number of feedback bits expressed in bytes. For CFB1 mode set this to 1 by rounding up to the nearest multiple of 8. diff --git a/crypto/evp/evp_locl.h b/crypto/evp/evp_locl.h index ef6c432..72105b0 100644 --- a/crypto/evp/evp_locl.h +++ b/crypto/evp/evp_locl.h @@ -127,9 +127,9 @@ BLOCK_CIPHER_def1(cname, cbc, cbc, CBC, kstruct, nid, block_size, key_len, \ #define BLOCK_CIPHER_def_cfb(cname, kstruct, nid, key_len, \ iv_len, cbits, flags, init_key, cleanup, \ set_asn1, get_asn1, ctrl) \ -BLOCK_CIPHER_def1(cname, cfb##cbits, cfb##cbits, CFB, kstruct, nid, 1, \ - key_len, iv_len, flags, init_key, cleanup, set_asn1, \ - get_asn1, ctrl) +BLOCK_CIPHER_def1(cname, cfb##cbits, cfb##cbits, CFB, kstruct, nid, \ + (cbits + 7)/8, key_len, iv_len, \ + flags, init_key, cleanup, set_asn1, get_asn1, ctrl) #define BLOCK_CIPHER_def_ofb(cname, kstruct, nid, key_len, \ iv_len, cbits, flags, init_key, cleanup, \ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CFB change
Dr. Stephen Henson st...@openssl.org writes: [...] Didn't realise anyone was using CFB for that. Is that some default or does it have to be specifically requested? It was explicitly requested, though I'm not sure for any positive reason in this case (more because we'd used that cipher and mode elsewhere, I think). I don't have any reason to think it's a default anywhere (well, I know some Isode software uses it, but apart from us...). I had been reading SP800-38a which says in 5.2: For the CFB mode, the total number of bits in the plaintext must be a multiple of a parameter, denoted s, that does not exceed the block size The parameter s is the number of feedback bits which would be 128 for CFB-128. The result of that change is to pad any incomplete final block using standard block padding rules. Though checking information in other places and looking at the algorithm this is clearly *not* a requirement because the last complete block can be used to produce a final incomplete block. I'll revert that change. OK, thanks. That sounds reasonable behaviour, and might avoid problems with BouncyCastle (presuming they don't make a similar change, of course). [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl ciphers fails when using !
Ben DJ bendj095124367913213...@gmail.com writes: [...] but, openssl ciphers -v HIGH:!RSA returns, RSA: Event not found. I think that's your shell, not openssl. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: freeing X509 structures
Matt Fioravante fmatthew5...@gmail.com writes: I've got some code that dynamically allocates an X509 object using PEM_read_X509 and then extracts some data from it. The problem is the object never gets freed. I tried to call free() on the X509 pointer but that doesn't work either because it has dynamically allocated sub structures. Is there any nice abstracted function for freeing these objects or do I have to dive into the struct itself and manually free everything? (which might all the sudden not work anymore if a new version of openssl comes out that changes the struct) I looked around in the x509 headers and didn't see anything. X509_free()? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about custom X509 extensions
decoder deco...@own-hero.net writes: [...] Ok, so what I am currently doing is something like asndata = ASN1_OCTET_STRING_new(); ASN1_OCTET_STRING_set(asndata, myData, myLength); and then I add asndata to an extension I create: ex = X509_EXTENSION_create_by_NID( NULL, nid, 0, asndata ); In the one case, myData was the hex encoded data, in the other case it was my raw binary data. Is the DER encoding included here and if not, how can I add it for the raw data? I think it's not. OpenSSL seems fine with the result, though, so perhaps you'll be OK. If you want to add in the extra layer, encode asndata using i2d_OCTET_STRING() then put the result of *that* into an ASN1_OCTET_STRING and pass the resulting ASN1_OCTET_STRING into X509_EXTENSION_create_by_NID(). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Providing certificates/keys as a buffer rather than a filename
Aravind GJ aravin...@gmail.com writes: [...] While functions like SSL_use_PrivateKey use EVP_PKEY structure, but to get that structure, I need to use BIO APIs which again takes filename as input. See BIO_new_mem_buf(). (There are other ways to construct EVP_PKEYs without reading from a file, depending what form you have the keys in.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Checking certificate chain
Plot Lost plot.l...@gmail.com writes: Hi, I'm trying to figure out how to check a certificate is valid according to a chain of certificates. There are 3 certs in all, and they are all held as X509 data in memory, e.g. X509 *server_cert; X509 *inter_cert; X509 *root_cert; How can I check that 'server_cert' is authenticated by 'inter_cert', and that in turn is authenticated by 'root_cert' ? Stick them in an X509_STORE_CTX and call X509_verify_cert(). See apps/verify.c for an example. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Checking certificate chain
Plot Lost plot.l...@gmail.com writes: [...] For this particular project I'm required to check each step individually, not the entire chain at once. That's what verifying the chain does (see the implementation of X509_verify_cert()). You could add a callback using X509_STORE_CTX_set_verify_cb(). That doesn't seem to have a separate manpage but reading the manpage for SSL_CTX_set_verify() should explain it. (SSL_CTX_set_verify() just sets the callback in X509_STORE_CTX.) How can I get verify_cert to say that the server cert is ok according to the inter cert, regardless of any other cert that may be needed to complete the chain. (The code will then go on to check inter against root, or against another inter etc as needed asuming each step is completed ok) Presuming using X509_verify_cert() and a callback really isn't suitable, you can use X509_check_issued() to see if one certificate issued another and check the signature by getting the public key (X509_get_pubkey()) and verifying using X509_verify(). Or something like that; really it seems safer to me to use X509_verify_cert(). There are checks that have to be performed in context which X509_verify_cert() does (path constraints, policy constraints, etc.), and it seems easy to skip a few if you're not careful. (See section 6 of RFC 5280.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl verify fails
Erik Tkal et...@juniper.net writes: Hi Michael, Your rootcacert is not a root cert, as it was issued by C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Client Authentication and Email. You need to append that cert as well to your CAfile. That seems to be a change in behaviour. 0.9.8o is happy: brs% openssl version OpenSSL 0.9.8o 01 Jun 2010 brs% openssl verify -verbose -CAfile rootcacert.pem subcacert.pem subcacert.pem: OK brs% openssl verify -issuer_checks -CAfile rootcacert.pem subcacert.pem subcacert.pem: /C=DE/O=SCA Deutsche Post Com GmbH/CN=Signtrust CERT Class 3 CA 3:PN error 29 at 0 depth lookup:subject issuer mismatch /C=DE/O=SCA Deutsche Post Com GmbH/CN=Signtrust CERT Class 3 CA 3:PN error 29 at 0 depth lookup:subject issuer mismatch /C=DE/O=SCA Deutsche Post Com GmbH/CN=Signtrust CERT Class 3 CA 3:PN error 29 at 0 depth lookup:subject issuer mismatch /C=DE/O=SCA Deutsche Post Com GmbH/CN=Signtrust CERT Root CA 1:PN error 29 at 0 depth lookup:subject issuer mismatch OK [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl verify fails
Erik Tkal et...@juniper.net writes: Maybe that's a bug in OpenSSL 0.9.8o? The docs for verify say It is an error if the whole chain cannot be built up. Maybe, but I think it's just as reasonable to regard it as a bug in the docs. I think it's useful for verify to be able to verify chains from trust anchors (whether or not they're root CAs), and that verify ought to regard -CAfile and -CApath as pointing at certificates representing such trust anchors. With that interpretation 0.9.8o is right and 1.0.0a appears to be wrong. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl verify fails
Dr. Stephen Henson st...@openssl.org writes: [...] Is that unmodified OpenSSL 0.9.8o? If so that's peculiar I get the expected error here. No, it's Debian's 0.9.8o-2. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl verify fails
Michael Ströder mich...@stroeder.com writes: Bruce Stephens wrote: [...] Ah, my fault. Obvious in retrospect: Debian's openssl finds the root cert because it's in the ca-certificates package! Did you use -CAfile as in my original posting when testing? I did. Doesn't -CAfile set exclusively all trusted CA certs? Apparently not, the normal openssl.cnf is read and (on Debian, if ca-certificates is installed) that gives a set of extra CA certificates. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: convert x509 cert into string and store certs in cache
ikuzar razuk...@gmail.com writes: [...] my questions : 1) What does DER format means ? Distinguished Encoding Rules. It's an encoding for ASN.1. See X.690. is it equivalent to a string format ? It's a binary serialisation. So it's a string in the sense that it can be sent over protocols, saved in files, etc., but it's not a C NUL-terminated string that you'd want to look at. [...] 2) is it possible to verify ( by hand ) certificate in string format ? Not really. With some effort you could verify some simple things like its length. 3) what kind of data structure ( vector, etc..) is the best way to store certificate with string format ? Anything which can store bytes and a length. So vectorunsigned char or std::string would be fine. I guess many programs which do networking will have some suitable class (or convention for what to use) for a sequence of bytes, so likely you'd use that. 4) is a bad idea to handle everywhere certificates in string format ? Depends. If you want to use OpenSSL's functions then you'll want an X509. If that's uncommon, then storing the encoded form might well make more sense. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CRL validation must be skipped for certs with no CRLDPs
Jeff Saremi jsar...@morega.com writes: [...] Section 6.3.3. of RFC 5280 - CRL Processing This algorithm begins by assuming that the certificate is not revoked For each distribution point (DP) in the certificate's CRL distribution points extension, for each corresponding CRL So my expectation is that after I instruct OpenSSL to perform CRL checking -- whether I set or not set any CRLs -- no checking must be done on any certificates which don't have CRLDP in them. I think you should read on. Specifically, the last paragraph seems to me to indicate different behaviour is intended: If the revocation status has not been determined, repeat the process above with any available CRLs not specified in a distribution point but issued by the certificate issuer. For the processing of such a CRL, assume a DP with both the reasons and the cRLIssuer fields omitted and a distribution point name of the certificate issuer. That is, the sequence of names in fullName is generated from the certificate issuer field as well as the certificate issuerAltName extension. After processing such CRLs, if the revocation status has still not been determined, then return the cert_status UNDETERMINED. That seems to me more natural: if there's no CRLDP then check any relevant CRL. If (after all this) you fail to find any relevant CRLs, then the revocation status is undetermined. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CRL validation must be skipped for certs with no CRLDPs
Jeff Saremi jsar...@morega.com writes:
[...]
Here's the code:
cert.status = NOT_REVOKED;
for (i = 0; i cert.crldp.size; ++i)
{
/* some processing loops */
if(cert.status == UNDETERMINED)
{
/* do what Bruce Stephens suggested */
}
}
No, I think RFC5280 is saying that you may have CRLs which were not
indicated by CRLDP. Even if there is no CRLDP at all, you may have
(through some other means) CRLs issued by some appropriate entity
(either the CA or a indirect CRL issuer).
If you don't have any of those (and you don't have any other mechanism
for verifying revocation status, such as OCSP) then that surely
shouldn't mean that the certificate is not revoked---it surely ought to
mean you don't know?
When designing your own applications you might reasonably choose to
regard such certificates as valid, or (alternatively) to reject them on
the grounds that revocation status can't be checked. Both seem
reasonable choices, depending on the circumstances.
I'm not sure what you should do if you're issuing certificates and want
people to always regard them as unrevoked. I suspect it depends how
much control you have over the software that other people are using. At
worst you might need to produce CRLs (which would always be empty) or
run an OCSP server.
[...]
Now as a result of OpenSSL's imlementation, none of my clients who use
OpenSSL will be able to deal with me online.
I don't think it has anything to do with OpenSSL. Other verifiers will
behave similarly (I happen to be familiar with CML and that'll behave
the same as OpenSSL, if revocation checking is enabled).
Because my certificates do not have a CRL and CRLDP period. Should I
stop doing business altogether? Should I contact my business partners
and tell them that they should be applying a patch to their code,
overriding verification failure in their certVerifyCallbacks? Let's
just think that through a little.
If you want to support software that performs revocation checking then
you'll need to provide some way for that software to check revocation
status. That might be simple (provide an empty CRL with a nextUpdate
way off in the future).
But maybe that's not necessary: for software that only really addresses
you certs, maybe you can persuade the software not to perform revocation
checking.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: CRL validation must be skipped for certs with no CRLDPs
Jeff Saremi jsar...@morega.com writes: [...] According to the RFC, is it an error for a certificate and its chain not to have any CRLs and CRL distribtuion points? No, but you're perhaps confusing things by joining the two together. On CRL DPs, this profile RECOMMENDS support for this extension by CAs and applications. On CRLs, the end of section 5 says Conforming CAs are not required to issue CRLs if other revocation or certificate status mechanisms are provided. [...] If the answer is no, then the body of code that is operating today on the Internet and is using SSL (think of it as browsers) should operate with no errors. In this sense, OpenSSL would be an exception because its default and natural implementation causes an error. Application writers have to consider what to do about revocation. One option is for an application to ignore the possibility of revocation, and OpenSSL can easily be used to do that. Otherwise the application must have some functionality to request OCSP, provide CRLs, etc. And (again) this is not specific to OpenSSL. Other certificate verifiers will (when asked to check revocation status) also reject certification paths where revocation status is unavailable. Any that don't do that are surely broken? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Cert chain verification failures
David Coulson da...@davidcoulson.net writes: [...] OpenSSL has other ideas. First one validates fine, second one does not. I can't for the life of me figure out what the difference is. Any ideas? Add the -showcerts option to the s_client commands and you'll see the first server returns a chain of certificates where the second offers only the end server certificate. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Cert chain verification failures
David Coulson da...@davidcoulson.net writes: On 3/29/11 12:58 PM, Bruce Stephens wrote: Add the -showcerts option to the s_client commands and you'll see the first server returns a chain of certificates where the second offers only the end server certificate. Okay, I see that - Makes sense. When I hit the hostname w/ Firefox I'm able to see a complete certificate chain. Where does it get that information from? It'll be built in. Web browsers have an improbably large number of certificates (many of them trusted) automatically available in some way (Firefox has its own database, IE uses some part of the Windows certificate store). [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
When should an application call ERR_clear_error()?
I was confused to find logging indicating an intermittent error while doing SSL in an application: x509 certificate routines:X509_check_private_key:key values mismatch:x509_cmp.c:318: But that's while running automated tests which always use certificates and keys from pregenerated PKCS#12 files. So that doesn't make sense. It continued to not make sense on further investigation. The error seems to be coming from a successful call to PKCS12_parse(): it's checking each certificate against the private key, and one of the certificates (unsurprisingly, since it's a CA) doesn't match. So what's the right thing to do? Should PKCS12_parse() be calling ERR_clear_error() (or something else) on success? Should the application call ERR_clear_error() after successfully calling PKCS12_parse(), and are there other functions that might need similar treatment? Should the application be calling ERR_clear_error() at some points as part of initialisation? Maybe just before creating an SSL or something? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
verify and the authority and issuer serial number mismatch error
I have a chain that fails to verify: brs% openssl verify -verbose -issuer_checks -CAfile serversTA.pem -untrusted 'servers-users.pem' dua.pem dua.pem: CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 31 at 0 depth lookup:authority and issuer serial number mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 20 at 0 depth lookup:unable to get local issuer certificate I think that's because dua.pem contains an AKID that does not match 'servers-users.pem' (it contains keyID, issuer and serial number). That's true but it's deliberate: servers-users.pem is a cross certificate (issued by serversTA.pem). The key matches (servers-users.pem has a public key that's the same as the public key of the actual issuer of dua.pem). Isn't OpenSSL just wrong in doing this? X.509 (2008) says Certification authorities shall assign certificate serial numbers such that every (issuer, certificate serial number) pair uniquely identifies a single certificate. The keyIdentifier form can be used to select CA certificates during path construction. The authorityCertIssuer, authoritySerialNumber pair can only be used to provide preference to one certificate over others during path construction. Isn't OpenSSL's use of authoritySerialNumber to reject the certificate technically incorrect (according to X.509, though I don't see anything in RFC 5280 permitting it either)? Presumably it's ordinarily harmless: OpenSSL's default config doesn't set authorityCertIssuer, authoritySerialNumber in AKID, and ordinarily everything would match up fine anyway. So to find a problem you'd need a setup with this not recommended AKID and cross certificates. So, lucky me! Presumably there's no test of this in PKITS? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
verify and the authority and issuer serial number mismatch error
I have a chain that fails to verify: brs% openssl verify -verbose -issuer_checks -CAfile serversTA.pem -untrusted 'servers-users.pem' dua.pem dua.pem: CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 31 at 0 depth lookup:authority and issuer serial number mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 20 at 0 depth lookup:unable to get local issuer certificate I think that's because dua.pem contains an AKID that does not match 'servers-users.pem' (it contains keyID, issuer and serial number). That's true but it's deliberate: servers-users.pem is a cross certificate (issued by serversTA.pem). The key matches (servers-users.pem has a public key that's the same as the public key of the actual issuer of dua.pem). Isn't OpenSSL just wrong in doing this? X.509 (2008) says Certification authorities shall assign certificate serial numbers such that every (issuer, certificate serial number) pair uniquely identifies a single certificate. The keyIdentifier form can be used to select CA certificates during path construction. The authorityCertIssuer, authoritySerialNumber pair can only be used to provide preference to one certificate over others during path construction. Isn't OpenSSL's use of authoritySerialNumber to reject the certificate technically incorrect (according to X.509, though I don't see anything in RFC 5280 permitting it either)? Presumably it's ordinarily harmless: OpenSSL's default config doesn't set authorityCertIssuer, authoritySerialNumber in AKID, and ordinarily everything would match up fine anyway. So to find a problem you'd need a setup with this not recommended AKID and cross certificates. So, lucky me! Presumably there's no test of this in PKITS? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Differences between RSA and ECDSA - Conceptual and Practical
Jakob Bohm jb-openssl-Ov0D3Su7/I/qt0dzr+a...@public.gmane.org writes: [...] As explained above, 192 bit DSA and ECDSA only works with 192 bit hashes (and only one hash algorithm is allowed for each private/public key pair). You can use larger digests (SHA-512, for example), but the digest will be truncated before processing with ECDSA (or DSA). (This behaviour is specified in the relevant standard.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Differences between RSA and ECDSA - Conceptual and Practical
Jakob Bohm jb-openssl-Ov0D3Su7/I/qt0dzr+a...@public.gmane.org writes: [...] I did mention that in passing under my item 2 (where I mentioned use of 192-bit-truncated-SHA-224 as one allowed 192 bit hash algorithm for use with ECDSA-192). OK, sorry, I missed that. I don't remember if the current FIPS-180 actually allows truncating to (below) the size of the next smaller standard SHA-2 variant, though there may be a special case allowing 160-bit-truncated-SHA-224 for use in former SHA-1 applications. My reading of FIPS 180-4 (section 7) is that it does allow quite general truncation. (I skipped to section 7, though, so perhaps that's restricted elsewhere.) FIPS 186-3 seems to permit larger digest sizes to be used (section 4.2), It is recommended that the security strength of the (L, N) pair and the security strength of the hash function used for the generation of digital signatures be the same unless an agreement has been made between participating entities to use a stronger hash function. (it goes on to describe the truncation to be performed). For Federal Government entities other than CAs it gives specific combinations to be used, and similarly for CAs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certification Authority's Database
sandeep kiran p sandeepkiranp-re5jqeeqqe8avxtiumw...@public.gmane.org writes: Hi, A quick question. Does the SubjectName in a certificate really need point to an LDAP DN in a X500 Directory that a CA uses or do CAs manage the SubjectName DNs without actually using any sort of Directory? I want to know whether it is a general practice for CAs not to maintain any LDAP Directories when issuing certificates with DNs. If it does not use DNs from an LDAP directory, how does the CA maintain a hierarchy for the SubjectName DNs it issues? If it is not done through a Directory, how does a CA maintain the list of certificates it issues to a particular Subject. Will it just be file system based storage? That's up to the CA. I imagine many use databases of other kinds, likely SQL. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: About the usage of SSL_get_ex_new_index
Bruce (Riji) Cai bcai-zm9q81nvl4ufkj6hysv...@public.gmane.org writes: Not quite sure, but to my understand, the ex_data is saved into per ssl connection context, so the index to it should be per connection scope. That's not correct, no. The ex_data mechanism can be used to store many different things into each SSL connection (similarly for other structures). Each such kind of thing can get its own index using SSL_get_ex_new_index, and so each can work independently on the same connection without interference. SSL_get_ex_new_index is giving an index for all SSL objects, not any specific one---it's a global operation. While from my observation, the returned index is increased when SSL_get_ex_new_index is called once, no matter called by A connection or B connection. In some case, I have only one private data, and I don't want to pass the index var to every piece of code, So use a global of some sort (file static or whatever). I don't see the problem. so can I just save the ex_data directly to index 0 and get it out from 0 when needed? You can, and maybe it'll be OK, but you risk conflicts if something else in your application also wants to use the ex_data mechanism on SSLs. Using SSL_get_ex_new_index correctly removes that possible problem (presuming the other code is also using it correctly, of course). [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: trust chain building for X509_verify_cert
Arthur Spitzer arthur.spitzer-nefzrhniqppqt0dzr+a...@public.gmane.org writes: [...] The problem is: The verification always fails with error code 7 (“signature invalid”). I already tried three different attempts (documented in the attached cpp file) to build the trust chain, with the same result. The relevant source code (certificates as char arrays included in the cpp) and both certificates are attached. I would be very grateful if you could give me a hint. Right now I am a little lost. You don't seem to be calling OpenSSL_add_all_algorithms() (or adding any algorithms). http://www.openssl.org/support/faq.html#PROG8 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl-valgrind-errors...
Anand Vasudevan [EMAIL PROTECTED] writes: Hi, am using libcurl(ver 7.15.4) which uses openssl libraries. When I ran my application with valgrind-3.1.0 in Fedora core 5, I observed some valgrind errors coming from open ssl library..any inputs? pls find the attached for the errors.. You probably want to build with -DPURIFY. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Extracting all extensions from a certificate
Christopher Kunz [EMAIL PROTECTED] writes: how can I extract all extensions from a certificate into a STACK_OF(X509_EXTENSION)? For certificate requests, there is X509_REQ_get_extensions that returns this stack, but how is that done with an actual certificate? X509_get_ext_count(), X509_get_ext(), and the usual stack macros STACK_OF(X509_EXTENSION), sk_X509_EXTENSION_push() and so on, I guess. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Extracting all extensions from a certificate
Christopher Kunz [EMAIL PROTECTED] writes: [...] Is there any up-to-date complete documentation available for the full function set of OpenSSL? For some of the stuff, like ASN.1 manipulation, I can't even find anything on Google... Not that I know of. I use Source Navigator (or OpenGrok---choose your own source indexer) and lots of guessing. The manpages (converted from perldoc, I guess) don't cover everything, and in particular don't cover what you're asking about, I think. I imagine documentation patches would be welcomed. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Encrypted page sending data through unencrypted connection?
Marcelo de Moraes Serpa [EMAIL PROTECTED] writes: [...] Does that mean that the developer made the link to the create account page via HTTPS (not important at all) and then forgot the really relevant part, which is to send the html form contents via HTTPS? Yes. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: C++ compatability
Saju Paul [EMAIL PROTECTED] writes:
It is very clear that you Thomas have never ever used the hmac routines !!
So how you entertain yourself is irrelevant to the problem being discussed.
thank you.
You'll need to give more information. For me, the following C++
program compiles, links (needs to link against -lcrypto -lssl), and
runs (printing the unexciting md_len = 20). This is using gcc (4.1)
on GNU/Linux, x86, with OpenSSL 0.9.8e.
#include openssl/ssl.h
#include openssl/hmac.h
#include strings.h
#include iostream
int
main(int, char *[])
{
SSL_library_init();
OpenSSL_add_all_algorithms();
const char key[] = hello;
const char data[] = some data to hash;
unsigned char md[EVP_MAX_MD_SIZE];
unsigned int md_len;
HMAC(EVP_sha1(), key, strlen(key),
reinterpret_castconst unsigned char*(data), strlen(data),
md, md_len);
std::cout md_len = md_len std::endl;
}
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: S/MIME with MUA's.
Dr S N Henson [EMAIL PROTECTED] writes: [...] There's a function X509_get1_email() which will retrieve a list of email addresses both from the subject name and subjectAltName extensions and arrange them in a STACK. From then its trivial to just compare each or use sk_find(). Currently there aren't any functions that handle things like different signing and encryption certificates or encryption capabilities. That has to be largely done manually. Gnus is an emacs-lisp package. It just calls the command-line version of "openssl smime", so what's required is some command-line interface to these features. From what you say, presumably it could be a flag to x509, which displays a list of email addresses, one per line? (Or something like that, anyway.) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: S/MIME with MUA's.
Dr S N Henson [EMAIL PROTECTED] writes: [...] Ah, I see. The x509 -email option of OpenSSL 0.9.6 does just that. So it does. Sorry, I should have RTFMed! I've passed this information on to the Gnus list, so with any luck, Gnus will be one of the first free MUAs to support S/MIME reasonably usably---to be fair, it's not *that* bad now, but it could be lots better. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
Andrew Cooke [EMAIL PROTECTED] writes: This isn't quite true - you can compile OpenSSL to be copyright free. You mean without the patented algrorithms, presumably? (i.e., "patent free" not "copyright free".) The code is still copyright, but the copyright looks pretty liberal (and wouldn't cover mere use of the software anyway). However, as far as I know (and my knowledge is a bit out-of-date, so this may have changed), this then leaves SSL with cipher suites which are not supported by the common browsers. Yes, I think that's still true. DSA and things are mandatory for TLS-1.0, but browsers don't support them (or not very well, anyway) yet. (It'll probably be a while until the browsers support these things properly---probably after next September when it won't matter anyway.) -- Bruce Stephens [EMAIL PROTECTED] MessagingDirect(UK) Ltd URL:http://www.MessagingDirect.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
How do I download a self-signed CA cert into IE/OE?
Suppose I want to get IE to trust a new CA for signing user certificates (for S/MIME in OE or something). How do I reliably do that? i.e., what format should I put the certificate in, what file extension should it have, and what MIME type should I have Apache give it? It ought to be easy: I ought to be able to produce a cacert.pem file, and deliver it as application/x-x509-ca-cert, which has the advantage that Netscape will grok it, too. And indeed, this seems to work. On some machines. But not on others. And sticking in DER form (can calling it cacert.der) similarly doesn't work reliably, either. So what's the right thing to do? -- Bruce Stephens [EMAIL PROTECTED] MessagingDirect(UK) Ltd URL:http://www.MessagingDirect.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL Root CA and Intermediate CA Certs.
Edward Ned Harvey (openssl) openssl-Z8efaSeK1ezqlBn2x/y...@public.gmane.org writes: From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Michael Wojcik For someone who does want more background in cryptography, I'd recommend Schneier's /Applied Cryptography/ over /Cryptography Engineering/. The latter is for people implementing cryptography, which beginners should never do. Huh - I thought Cryptography Engineering was the 3rd edition of Applied Cryptography, renamed. But now I look at it, it seems you're right, it's a different book entirely. Second edition of Practical Cryptography: https://www.schneier.com/book-practical.html However, I never got the impression that Cryptography Engineering was meant for people implementing new algorithms or anything like that. True, implementing isn't quite the right word. Using would be closer, I suspect, though that doesn't necessarily carry the notion of engineering (it's not a book about how to use PGP, or use some product that incorporates TLS). [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
X509_NAME canon_enc, canon_enclen
I have some code accessing these fields from X509_NAME pointers, but obviously that's not allowed in 1.1. I think the code can be restructured to use X509_NAME_cmp instead. Maybe. But before I start that, is there some strong reason for not offering an accessor function? Something like X509_NAME_get0_canonenc(const X509_NAME*, const unsigned char* *canonenc, unsigned int *canon_len)
Using X509_verify_cert with (possibly) OCSP?
Suppose I want to verify a certificate, and I've collected some CRLs and some OCSP responses. How can I do that? If I just want to verify revocation for the end certificate (so X509_V_FLAG_CRL_CHECK rather than X509_V_FLAG_CRL_CHECK_ALL) then that's straightforward: I use X509_verify_cert without those settings and then do the OCSP check for the end certificate. But how can I check the whole chain, using some mixture of CRLs and OCSP? It looks like I can use verify_cb and perform my own checks when the error is X509_V_ERR_UNABLE_TO_GET_CRL. I think really what I'd want is to have some more low-level callback used in check_cert or check_revocation, but I don't see one. In 1.0.2 I'm just changing check_revocation (since ) but in order to keep the usual CRL checking that involved basically copying check_cert and a bunch of related functions with small changes to one or two of them (because they're mostly static so I can't just call them). In OpenSSL-1.1 that doesn't look so attractive (and it's not terribly pretty with 1.0.2) because the code accesses things in X509 and X509_CRL that aren't accessible. Am I missing something obvious? Does the TLS code do this in some way? (It doesn't look like it does, but possibly I'm just missing it.)
