RE: Please Help: Certificate Validation using subjectAltName extension
Thanks Dave for explanation. One doubt regarding sentence " If a subjectAltName extension of type dNSName is present, that MUST be used as the identity(RFC 2818)" What does this line means ? Does it says if a certificate have different CN in issuer & subject field but SubAltname: x.x.x.x which matches with HOST.URL (server) then will handshake goes through ? i.e. [ certificate_extensions ] basicConstraints = CA:false subjectAltName = DNS:x.x.x.x DNS:localhost [ req_distinguished_name ] countryName= US stateOrProvinceName= Chems localityName = Washington organizationName = Sercomm commonName = Verisign [ req_extensions ] basicConstraints = CA:true subjectAltName = DNS:x.x.x.x,DNS:localhost Am i correct ? Please help. Best Regards, S S rout -- View this message in context: http://old.nabble.com/Please-Help%3A-Certificate-Validation-using-subjectAltName-extension-tp32906983p33873612.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL_Certificate Validation ( Server Authentication): Please Help
Hey Crypto guys, I have a basic questions regarding Certificate validation. Basically in a Server Authentication a TLS client should validate the CN/SN with Host portion of the ACS.URL. If it matches then handshake will succeed else will fail. Am I right ? e.g. if Host.Url=x.x.x.x then CN (in both subject & issuer field should be x.x.x.x ) for self-signed certificate. Issuer: C=IN, ST=Karnataka, L=Bangalore, O=AN, CN=www.https.com Subject: C=IN, ST=Karnataka, L=Bangalore, O=AN, CN=www.https.com if Host.Url=x.x.x.x then CN (in subject field should be x.x.x.x ) for CA-Signed certificate Issuer: C=IN, ST=Karnataka, L=Bangalore, O=AN, CN=Veisign Subject: C=IN, ST=Karnataka, L=Bangalore, O=AN, CN=10.204.4.69 CN validation using self-signed certificate. SN validation: 1) Using CA signed certificate : using Subject name as HostURL 2) Using CA signed certificate : using subAltname as HostUrl Method for CN validation: 1) Keep the same Self-signed cert at both side (FAP & Server) Method for SN validation: 1) Keep ROOT cert at FAP and server cert (signed cert) at Server. Am I right guys ? Please let me know. Best Regards, S S rout -- View this message in context: http://old.nabble.com/SSL_Certificate-Validation-%28-Server-Authentication%29%3A-Please-Help-tp33873598p33873598.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: AES-GCM Gives Wrong Tag Value?
On Fri, May 18, 2012, Li, David wrote: > Hi Experts, > > First time I am using AES-GCM mode to run the NIST test vectors. The API is: > > void AES_gcm128_encrypt(GCM128_CONTEXT *ctx, > const unsigned char *in, unsigned char *out, > size_t len) > > > After initialization and encryption, my cipher text matched the one from NIST > vector but tag value didn't. I obtained the tag value by: > > Unsigned char tag[16]; > memcpy(tag, ctx.Xi.c, 16); > > Anyone can think of a reason what might have gone wrong? > Don't use the low level APIs: use EVP instead. There is program fips/aes/fips_gcmtest.c which has already been put through the FIPS 140-2 validation tests on a number of platforms. That uses the special FIPS api but it isn't hard to see the equivalent functions for "normal" EVP. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: AES-GCM Gives Wrong Tag Value?
David: This is just a quick and dirty superficial guess, but are you copying from the correct place in memory? I.e., is the value of: ctx.Xi.c, a pointer to the address that holds the first byte of the tag? If you do a byte-wise dump of the entire structure and then do visual pattern matching for the tag (which you already know), then you can count the offset, etc. And, then you can see if the numerical value of ctx.Xi.c points to the correct address. Good luck On Fri, May 18, 2012 at 10:22 AM, Li, David wrote: > Hi Experts, > > ** ** > > First time I am using AES-GCM mode to run the NIST test vectors. The API > is: > > ** ** > > void AES_gcm128_encrypt(GCM128_CONTEXT *ctx, > > const unsigned char *in, unsigned char *out, > > size_t len) > > ** ** > > ** ** > > After initialization and encryption, my cipher text matched the one from > NIST vector but tag value didn’t. I obtained the tag value by: > > ** ** > > Unsigned char tag[16]; > > memcpy(tag, ctx.Xi.c, 16); > > ** ** > > Anyone can think of a reason what might have gone wrong? > > ** ** > > **- **David > > ** ** > > ** ** > > The test vectors from NIST look like: > > > > [Keylen = 256] > > [IVlen = 128] > > [PTlen = 1024] > > [AADlen = 1024] > > [Taglen = 120] > > ** ** > > Count = 0 > > Key = ec566324ad9d4cd015821e2cd4ed4d3d507bdb3c65bd50acc85f690ef06740fa > > PT = > 348d35768d7192415cbb92c5625f10edd79f24c56d4b821aaf80d7dc83e901ede6be94d1efe11a3acd16ac00aea8d0d4875c47522332fed11cdf0816b26978de431c89d2fe6d122b2d4980f1d53a97edc15e490a44e73cba9394ca4bbb871675c729c39de80d6678c71b1bd220e4647bfd20a7ddbefe2b7eec7276b87c92ba77 > > > AAD = > fa6f38f8e562a54bb2281dc9a7cbe0b981292fb00dc0053185550a300661852179d0f2beb4e7759b81316fbfead5c858e6fce73f3cd2c2462925dbb199a4e6c121d051b1b5ebf60e16d1e30f6973b19cf31830da30588fdfff6115a4a1f6d977a72583379a56055724581be5232b0d1b0ae88bab5d4a031b058bc8d03078dcd5 > > > IV = 95c8a544c4b94e9fbfd76e66f40bb975 > > CT = > 8b4da79f3ae1ea35a80af2f52fc640055e6a3b92617ddfa79fe5d8a49f28ddf36a82a17ca0b3cdf1726700f7ffc09ae5b412d064fd52a90a76bacc74a0b89e38dc474e880a2b768ffa91fef34c47759a7b8fd7faa32a4fcb258349495e4438c7b2055a8f462729fa4e7223aa9b47087695e3aabf43afb32e272d536b257b748a > > > Tag = b1faec277697add8f756391dd9c7f4 > > ** ** > > ** ** > -- Slavish adherence to ideology in the pursuit of power leads to magical thinking and regrettable behavior. John Zavgren 603-371-0513 (home) 603-801-2094 (cell) johnzavgren (skype) 603-821-0904 (skype) j...@zavgren.com
AES-GCM Gives Wrong Tag Value?
Hi Experts, First time I am using AES-GCM mode to run the NIST test vectors. The API is: void AES_gcm128_encrypt(GCM128_CONTEXT *ctx, const unsigned char *in, unsigned char *out, size_t len) After initialization and encryption, my cipher text matched the one from NIST vector but tag value didn't. I obtained the tag value by: Unsigned char tag[16]; memcpy(tag, ctx.Xi.c, 16); Anyone can think of a reason what might have gone wrong? - David The test vectors from NIST look like: [Keylen = 256] [IVlen = 128] [PTlen = 1024] [AADlen = 1024] [Taglen = 120] Count = 0 Key = ec566324ad9d4cd015821e2cd4ed4d3d507bdb3c65bd50acc85f690ef06740fa PT = 348d35768d7192415cbb92c5625f10edd79f24c56d4b821aaf80d7dc83e901ede6be94d1efe11a3acd16ac00aea8d0d4875c47522332fed11cdf0816b26978de431c89d2fe6d122b2d4980f1d53a97edc15e490a44e73cba9394ca4bbb871675c729c39de80d6678c71b1bd220e4647bfd20a7ddbefe2b7eec7276b87c92ba77 AAD = fa6f38f8e562a54bb2281dc9a7cbe0b981292fb00dc0053185550a300661852179d0f2beb4e7759b81316fbfead5c858e6fce73f3cd2c2462925dbb199a4e6c121d051b1b5ebf60e16d1e30f6973b19cf31830da30588fdfff6115a4a1f6d977a72583379a56055724581be5232b0d1b0ae88bab5d4a031b058bc8d03078dcd5 IV = 95c8a544c4b94e9fbfd76e66f40bb975 CT = 8b4da79f3ae1ea35a80af2f52fc640055e6a3b92617ddfa79fe5d8a49f28ddf36a82a17ca0b3cdf1726700f7ffc09ae5b412d064fd52a90a76bacc74a0b89e38dc474e880a2b768ffa91fef34c47759a7b8fd7faa32a4fcb258349495e4438c7b2055a8f462729fa4e7223aa9b47087695e3aabf43afb32e272d536b257b748a Tag = b1faec277697add8f756391dd9c7f4
Re: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
On Thu, May 17, 2012, Greg Wittmeyer wrote: > Hello all, hope someone can help. > > I upgraded from 1.0.0d to 1.0.1c and immediately started getting this error: > > error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number > It's a known issue. The latest snapshots could fix it, or apply this patch to 1.0.1c: http://cvs.openssl.org/chngview?cn=22565 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Custom sequences & Copy
Gentle people,
I am encoding some extra fields in the request (and the signed cert). And have
two related puzzels:
1) I had naively expected below construct to create a single sequence of
two object/integers under a single object:
# openssl.cnf snippet.
[v3_screen]
basicConstraints=CA:FALSE
...
1.3.6.1.4.1.2692.99.31=ASN1:SEQUENCE:seq_geo
…
[seq_geo]
1.3.6.1.4.1.2692.99.31.1=INTEGER: 1234
1.3.6.1.4.1.2692.99.31.2=INTEGER: 1234
but instead am seeing a construct which is just a sequence of two bare
INTs under a object:
ASN1_SEQUENCE(GeoLoc) = {
ASN1_SIMPLE(GeoLoc, lat, ASN1_INTEGER),
ASN1_SIMPLE(GeoLoc, lon, ASN1_INTEGER),
}
ASN1_SEQUENCE_END(GeoLoc)
i.e. prefix.1->[int,int]. While I had hoped for prefix.1->[
prefix.1.1:int, prefix.1.2:int ]. Which is not ideal - as occasionally the Geo
sequence needs to include the hight and the map projection as additonal
optional extra's.
How does one properly define such a sequence within the constraints of
the openssl.cnf file (I am currently doing it through the API - and that is
fine) ?
2) When one has fields like the above in a REQ - you need to copy them
into the signed cert. How is this done in a controlled way through the
openssl.cnf/extension file mechanism ?
Is there the equivalent of the 'copy' as available for the
email/subject ?
Thanks,
Dw.__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
