Re: [openssl-users] How many SAN entries...?

2017-04-26 Thread Jeffrey Walton 
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...?

2017-04-26 Thread Alan Buxey 
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...?

2017-04-26 Thread Blumenthal, Uri - 0553 - MITLL 
> 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...?

2017-04-26 Thread Viktor Dukhovni 

> 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...?

2017-04-26 Thread Salz, Rich via openssl-users 
> 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...?

2017-04-26 Thread Blumenthal, Uri - 0553 - MITLL 
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

2017-04-26 Thread Ryan Murray 
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

2017-04-26 Thread Ryan Murray 
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

2017-04-26 Thread Viktor Dukhovni 

> 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

2017-04-26 Thread Murray, Ronald-1 (ANF) 
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++)?

2017-04-26 Thread lists 

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

2017-04-26 Thread Viktor Dukhovni 

> 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

2017-04-26 Thread Matt Caswell 


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