Re: [openssl-users] How many SAN entries...?
On Wed, Apr 26, 2017 at 1:03 PM, Blumenthal, Uri - 0553 - MITLL wrote: > A naïve question. A certificate that contains SAN attribute(s) – is there a > limit on how many, say, RFC822 SAN attributes can a valid certificate have? > > > > It’s been my understanding that a cert can contain as many SAN attributes as > needed, but it appears that Apple believes it has to be only one (because > certificates with more than one are not processed properly). Lol... Apple is notorious for their defective and untested software. I'm pretty sure they don't have a QA department. Also see https://news.ycombinator.com/item?id=11034071. Worse, when a bug is reported through their RADAR, it goes unfixed. They force users into QA, and then don't fix the bugs that are reported. Jeff -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How many SAN entries...?
confirmed, i've seen dozens on one cert - far more preferable to do that and have such numbers than a single wildcard cert (which has issues on all sorts of platforms for various purposes). alan On 26 April 2017 at 18:24, Blumenthal, Uri - 0553 - MITLL wrote: > > It’s been my understanding that a cert can contain as many SAN > attributes as needed, > > but it appears that Apple believes it has to be only one (because > certificates with > > more than one are not processed properly). > > Perhaps CAs have rarely issued email certificates with multiple email > addresses. > > :-) > > OpenSSL will accept multiple email SANs and with email name checks will > accept > the certificate as valid so long as *one* of the addresses is a match. > > Thank you! That’s what I expected and hoped for. Appreciate the help! > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How many SAN entries...?
> It’s been my understanding that a cert can contain as many SAN attributes as needed, > but it appears that Apple believes it has to be only one (because certificates with > more than one are not processed properly). Perhaps CAs have rarely issued email certificates with multiple email addresses. :-) OpenSSL will accept multiple email SANs and with email name checks will accept the certificate as valid so long as *one* of the addresses is a match. Thank you! That’s what I expected and hoped for. Appreciate the help! smime.p7s Description: S/MIME cryptographic signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How many SAN entries...?
> On Apr 26, 2017, at 1:03 PM, Blumenthal, Uri - 0553 - MITLL > wrote: > > A naïve question. A certificate that contains SAN attribute(s) – is there a > limit > on how many, say, RFC822 SAN attributes can a valid certificate have? None of the standard SAN types (DNS, Email, IP, ...) are limited to just one entry. If you try to have hundreds of them, eventually the certificate may become too big for various protocols, but that's an explicit limit on the SAN multiplicity. > It’s been my understanding that a cert can contain as many SAN attributes as > needed, > but it appears that Apple believes it has to be only one (because > certificates with > more than one are not processed properly). Perhaps CAs have rarely issued email certificates with multiple email addresses. > Sanity check: please validate – am I correct that having, say, two RFC822 > email > addresses in one cert is OK? OpenSSL will accept multiple email SANs and with email name checks will accept the certificate as valid so long as one of the addresses is a match. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How many SAN entries...?
> A naïve question. A certificate that contains SAN attribute(s) – is there a > limit on how many, say, RFC822 SAN attributes can a valid certificate have? No. > It’s been my understanding that a cert can contain as many SAN attributes as > needed, but it appears that Apple believes it has to be only one (because > certificates with more than one are not processed properly). I can guess at, and understand, their reasoning -- it allows mail spoofing and stealing. And the use of such certs is not common. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] How many SAN entries...?
A naïve question. A certificate that contains SAN attribute(s) – is there a limit on how many, say, RFC822 SAN attributes can a valid certificate have? It’s been my understanding that a cert can contain as many SAN attributes as needed, but it appears that Apple believes it has to be only one (because certificates with more than one are not processed properly). Sanity check: please validate – am I correct that having, say, two RFC822 email addresses in one cert is OK? — Regards, Uri smime.p7s Description: S/MIME cryptographic signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RFC2818 and subjectAltName
yes Sent from Mail for Windows 10 From: Murray, Ronald-1 (ANF) Sent: Wednesday, April 26, 2017 1:25 PM To: 'openssl-users@openssl.org' Subject: [openssl-users] RFC2818 and subjectAltName We had an issue a few days ago when people with the newest version of Chrome were seeing security errors on our internal sites which were using SSL certificates signed with our internal CA. This turned out to be caused by Google adhering to RFC2818, which says: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Our certificates, of course, only contained the Common Name (CN), with no subjectAltName (SAN). I solved the problem by creating new certificates and hacking openssl.cnf to request a SAN in the CSR. Now, our CA isn’t openssl-based (it’s Microsoft), but it’s occurred to me that openssl-created certificates should really include the site ID in a SAN as well as in the CN. RFC2818 has been out since May, 2000, so I’m rather surprised that this hasn’t been widely implemented before now. I note that certificates we get from Symantec have lately included a SAN, but I think that’s quite recent. Is there any chance of this being included in openssl? This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this mail in error please notify the postmaster at dor.state.ma.us. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RFC2818 and subjectAltName
If you are asking me, by all means yes. Thanks for asking, I respect the value of honesty in world that has so very few people left. Sent from Mail for Windows 10 From: Viktor Dukhovni Sent: Wednesday, April 26, 2017 1:55 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] RFC2818 and subjectAltName > On Apr 26, 2017, at 11:55 AM, Murray, Ronald-1 (ANF) > wrote: > > Our certificates, of course, only contained the Common Name (CN), with no > subjectAltName (SAN). I solved the problem by creating new certificates and > hacking openssl.cnf to request a SAN in the CSR. An appropriate openssl.cnf is the supported way to populate DNS altnames into certificates created with the req(1), x509(1) and ca(1) utilities. > Is there any chance of this being included in openssl? It is already included, via the openssl.cnf interface. You can also create openssl.cnf sections on the fly, without creating any persistent files, with "bash" or similar shells. See, for example: https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RFC2818 and subjectAltName
> On Apr 26, 2017, at 11:55 AM, Murray, Ronald-1 (ANF) > wrote: > > Our certificates, of course, only contained the Common Name (CN), with no > subjectAltName (SAN). I solved the problem by creating new certificates and > hacking openssl.cnf to request a SAN in the CSR. An appropriate openssl.cnf is the supported way to populate DNS altnames into certificates created with the req(1), x509(1) and ca(1) utilities. > Is there any chance of this being included in openssl? It is already included, via the openssl.cnf interface. You can also create openssl.cnf sections on the fly, without creating any persistent files, with "bash" or similar shells. See, for example: https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] RFC2818 and subjectAltName
We had an issue a few days ago when people with the newest version of Chrome were seeing security errors on our internal sites which were using SSL certificates signed with our internal CA. This turned out to be caused by Google adhering to RFC2818, which says: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Our certificates, of course, only contained the Common Name (CN), with no subjectAltName (SAN). I solved the problem by creating new certificates and hacking openssl.cnf to request a SAN in the CSR. Now, our CA isn't openssl-based (it's Microsoft), but it's occurred to me that openssl-created certificates should really include the site ID in a SAN as well as in the CN. RFC2818 has been out since May, 2000, so I'm rather surprised that this hasn't been widely implemented before now. I note that certificates we get from Symantec have lately included a SAN, but I think that's quite recent. Is there any chance of this being included in openssl? ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this mail in error please notify the postmaster at dor.state.ma.us. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] QcStatements with OpenSSL (C++)?
On 04/17/2017 06:40 PM, Matthias Ballreich wrote:
Hi there,
can OpenSSL pasre QcStatement X509v3 Extension btw. Did OpenSSL
Support these?
Any Piece of example Code of how can i parse the data?
To my knowledge, there is direct support for the qcStatements, you must
parse it yourself.
I asked for some help on the list more or less a month ago, I was trying
to develop the required structures but apparently I got lost in the
OpenSSL macro jungle, finally I had to quit working on it.
What you can do is search for specific statements of interest to you
(there are quite a bit) by parsing the attribute.
Get the attribute NID of the object in the extension and see if it
matches the NID of qcStatements:
oneObj = X509_EXTENSION_get_object(oneExt);
objnid = OBJ_obj2nid(theObj);
if (objnid == NID_qcStatements)
{ printf("DEBUG:ext:GOTCHA!:this is qcStatements!\n"); }
you then extract the data from the object and parse it.
For the moment I have this ugly quick way of doing it, for instance for
a simple one:
#define UC_id_etsi_qcs_QcCompliance "0.4.0.1862.1.1"
if (strstr(extdump, UC_id_etsi_qcs_QcCompliance) == NULL)
{ printf("INFO:QcCompliance:no:\n"); }
else
{ printf("INFO:QcCompliance:yes:\n"); }
Thanks
Matthias
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to debug SSLV3_ALERT_BAD_RECORD_MAC
> On Apr 26, 2017, at 3:39 AM, Matt Caswell wrote: > > I'd start by looking at the end-to-end pipe between the client SSL/TLS > stack and the server stack and validating that the records look sane and > unchanged at each step. Well before that, I'd try to find out what's different about the 1.0.2k handshake, by comparing the negotiated protocol, ciphersuite and extensions with those negotiated with the previous version used. It would be appropriate to post which version of OpenSSL was used previously. It is also important to make sure that the headers and dev libraries are from the same 1.0.2 release and that the run-time libraries are in fact also from 1.0.2 (same patch level or higher). -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to debug SSLV3_ALERT_BAD_RECORD_MAC
On 25/04/17 22:37, craig_we...@trendmicro.com wrote: > We have recently upgraded our product to 1.0.2k. We are getting this > error on a packet sent to us from our browser-based user interface. I > really need some suggestions as to how to debug this problem. I know it > is in our code rather than OpenSSL but I have no idea how to dig into > what is happening. Is this a reproducible problem? Normally bad_record_mac would only occur if there was some implementation issue in the SSL/TLS stack itself or if something is corrupting the records after they have been generated by the stack. I'd start by looking at the end-to-end pipe between the client SSL/TLS stack and the server stack and validating that the records look sane and unchanged at each step. If that doesn't pin-point the problem then you may need to dig a little deeper. bad_record_mac can cover a multitude of sins. You need to figure out what specific sin you are committing. If it was me I would be instrumenting the OpenSSL code in this area to see what it thinks it is barfing on. You might want to start with the tls1_enc() function in ssl/t1_enc.c. If its a non-AEAD ciphersuite then you may need to look at tls1_mac() too (also in ssl/t1_enc.c). Possibly parts of ssl3_get_record() in ssl/s3_pkt.c Hope that helps, Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
