Re: Increment certificate serial numbers randomly
On 30.04.2014 03:57, Nikolay Elenkov wrote: What hasn't been suggested is giving each server, etc. its own sub-CA signed by the root. Then there won't be a need to have the root key at multiple places and not problems with serial. Additionally, clients will only have to install and trust the root, which should make the whole thing easier to deploy. I already mentioned this solution (not me has the many servers): this is a design failure; the certificates MUST all be signed on only one server for this reason; or each server must have its own root/intermediate CA; I want just come back to Jakob Bohm I seem to (vaguely) recall that there was once an option or standard for using a certificate-contents-related hash as the serial number, but I can't seem to find it right now. if he has already found this - I'd use it for a totally different purpose; smime.p7s Description: S/MIME Cryptographic Signature
TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version)
This time the client hello and server hello is done,but when client key exchange the server reply Alert (Level: Fatal, Description: Protocol Version).Shows bellow, what wrong with this? And I kown this alert means the client is not using the same protocol, but why client hello ,and server hello done? zyf01...@gmail.com
Re: Increment certificate serial numbers randomly
On 29.04.2014 22:32, Tim Hudson wrote: On 30/04/2014 6:05 AM, Walter H. wrote: On 29.04.2014 21:38, d...@deadhat.com mailto:d...@deadhat.com wrote: This all seems unecessarily complex. Make the serial number a 256 bit or greater true random number. There will be no collisions. the serial number has maximum length ..., 256 bit is quite too big .. In X.509 terms the serial number is an ASN1 integer value so there is no real length limit. the maximum length is defined by the use of them; e.g. FF/TB accept only 128 bit or in other words, they function properly with longer serial numbers; smime.p7s Description: S/MIME Cryptographic Signature
Re: TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version)
On Wed, Apr 30, 2014 at 3:04 AM, zyf01...@gmail.com zyf01...@gmail.comwrote: This time the client hello and server hello is done,but when client key exchange the server reply Alert (Level: Fatal, Description: Protocol Version).Shows bellow, what wrong with this? And I kown this alert means the client is not using the same protocol, but why client hello ,and server hello done? According to RFC 5246, section 7.2.2 ( http://tools.ietf.org/html/rfc5246#section-7.2.2): protocol_version The protocol version the client has attempted to negotiate is recognized but not supported. (For example, old protocol versions might be avoided for security reasons.) This message is always fatal. Try diagnosing further with: openssl s_client -ssl3 -connect server:port And openssl s_client -tls1 -connect server:port -servername:server The docs on s_client can be found at https://www.openssl.org/docs/apps/s_client.html. The server should be capable of TLS 1.0 in 2014. However, it might want TLS 1.2 too if its taking a defensive posture or providing only TLS 1.2 cipher suites. You can test for TLS 1.2 with * '-tls1_2'.*Jeff
Re: Increment certificate serial numbers randomly
Some standards (like the CA/Browser Forum guidelines) request a certain amount
of entropy (like 20 bits) to be contained within the serial number. Is there
some sort of best-practice for incorporating this small amount of real random
data into a larger unique serial number?
cheers
Mat
On Tuesday 29. April 2014 21:59:10 you wrote:
All of these approaches have already been suggested in this thread. Is it
really necessary that we go through them again?
Rich Salz's suggestion of using a UUID for the serial number makes
collisions sufficiently improbable that the possibility can be ignored, and
it's simpler than any of the other proposals.
Michael Wojcik
Technology Specialist, Micro Focus
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Tim Hudson Sent:
Tuesday, 29 April, 2014 16:32
To: openssl-users@openssl.org
Subject: Re: Increment certificate serial numbers randomly
On 30/04/2014 6:05 AM, Walter H. wrote:
On 29.04.2014 21:38, d...@deadhat.commailto:d...@deadhat.com wrote:
This all seems unecessarily complex. Make the serial number a 256 bit or
greater true random number. There will be no collisions.
the serial number has maximum length ..., 256 bit is quite too big ..
In X.509 terms the serial number is an ASN1 integer value so there is no
real length limit. It is also pretty common to see the output of a HASH
operation used as a serial number in a certificate. However in the context
of everyone separately picking an RNG output value (on separate systems)
there is no guarantee of zero collisions.
If you are installing the same root on multiple machines that don't
coordinate then just auto-edit the serial file (if using the ca program)
and put a unique prefix on the front. Perhaps just grab the machine MAC and
add that in. And then the auto-incrementing handling will sort that out.
The serial number format is simply a hex string value.
e.g. something like this could work (and there are better ways to do this -
it is just to get you started down a path that may solve the original
posters immediate issue)
ifconfig eth0 | grep HWaddr| awk '{print $NF}'| sed -e 's/://g'; echo
00 path-to-ca-serial-file
Tim.
Click herehttps://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== to
report this email as spam.
This message has been scanned for malware by Websense. www.websense.com
signature.asc
Description: This is a digitally signed message part.
Re: Re: TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version)
On Wed, Apr 30, 2014 at 3:04 AM, zyf01...@gmail.com zyf01...@gmail.comwrote: This time the client hello and server hello is done,but when client key exchange the server reply Alert (Level: Fatal, Description: Protocol Version).Shows bellow, what wrong with this? And I kown this alert means the client is not using the same protocol, but why client hello ,and server hello done? According to RFC 5246, section 7.2.2 ( http://tools.ietf.org/html/rfc5246#section-7.2.2): protocol_version The protocol version the client has attempted to negotiate is recognized but not supported. (For example, old protocol versions might be avoided for security reasons.) This message is always fatal. Try diagnosing further with: openssl s_client -ssl3 -connect server:port And openssl s_client -tls1 -connect server:port -servername:server The docs on s_client can be found at https://www.openssl.org/docs/apps/s_client.html. The server should be capable of TLS 1.0 in 2014. However, it might want TLS 1.2 too if its taking a defensive posture or providing only TLS 1.2 cipher suites. You can test for TLS 1.2 with * '-tls1_2'.*Jeff
Re: Re: TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version)
I have tryed, it works well. So ,what wrong with my appliction? zyf01...@gmail.com From: Jeffrey WaltonDate: 2014-04-30 15:27To: OpenSSL Users ListSubject: Re: TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version) On Wed, Apr 30, 2014 at 3:04 AM, zyf01...@gmail.com zyf01...@gmail.com wrote: This time the client hello and server hello is done,but when client key exchange the server reply Alert (Level: Fatal, Description: Protocol Version).Shows bellow, what wrong with this? And I kown this alert means the client is not using the same protocol, but why client hello ,and server hello done? According to RFC 5246, section 7.2.2 (http://tools.ietf.org/html/rfc5246#section-7.2.2): protocol_version The protocol version the client has attempted to negotiate is recognized but not supported. (For example, old protocol versions might be avoided for security reasons.) This message is always fatal. Try diagnosing further with: openssl s_client -ssl3 -connect server:port And openssl s_client -tls1 -connect server:port -servername:server The docs on s_client can be found at https://www.openssl.org/docs/apps/s_client.html. The server should be capable of TLS 1.0 in 2014. However, it might want TLS 1.2 too if its taking a defensive posture or providing only TLS 1.2 cipher suites. You can test for TLS 1.2 with '-tls1_2'. Jeff
Re: Windows CE (VC-CE) Compilation problem !
I use wcecompat with OpenSSL for WinCE 2.11; I haven't tried building
for a later version of WinCE, and I use an older compiler. There's
some basic problem with your build; it looks like something as basic
as using a C compiler to compile C++ and getting tripped up on new
syntax. Are you able to build a hello, world program for WinCE?
I remember one issue I had with wcecompat was that the configure
script didn't get the include paths right, particularly for paths that
included spaces.
-Geoffrey
On 04/28/2014 08:58, karan.reddy karan.ti...@gmail.com wrote:
Hi,
I am very new to Openssl. My aim is to compile openssl for WINCE 6.0
OS. After spending lot of time on google , i found procedure to
build openssl for WINCE 6.0. But my attempt to build the wcecompat
WINCE runtime libraries is unsuccessful. Below is my environment
Host Platform : WINDOWS 7
Visual Studio : 2008
TargetCpu : x86
Below are the steps followed to build wcecompat:
1) Downloaded the source from
https://github.com/mauricek/wcecompat/tree/master; git.
2) Using Visual Studio Command prompt for build. Declared the env
following variables:
set OSVERSION=WCE600
set TARGETCPU=x86
set PLATFORM=VC-CE
3) Created the make files using perl config.pl command.
4) Executed nmake command.
The build fails with compilation errors. Below are the logs:
--
args.cpp
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(235)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(237)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(239)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(241)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(243)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(245)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(247)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(249)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(251)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(253)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(255)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(257)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(258)
: error
C2059: syntax error : '('
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(994)
: error
C2556: 'const wchar_t *wcschr(const wchar_t *,wchar_t)' : overloaded
function differs only by return type from 'wchar_t *wcschr(const
wchar_t
*,wchar_t)'
include\string.h(36) : see declaration of 'wcschr'
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\wchar.h(994)
: error
C2373: 'wcschr' : redefinition; different type modifiers
include\string.h(36) : see declaration of 'wcschr'
C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE\wchar.h(1026) :
error C2556: 'const wchar_t *wcspbrk(const wchar_t *,const wchar_t
*)' :
overloaded function differs only by return type from 'wchar_t
*wcspbrk(const
wchar_t *,const wchar_t *)'
include\string.h(46) : see declaration of 'wcspbrk'
C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE\wchar.h(1026) :
error C2373: 'wcspbrk' : redefinition; different type modifiers
include\string.h(46) : see declaration of 'wcspbrk'
C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE\wchar.h(1027) :
error C2556: 'const wchar_t *wcsrchr(const wchar_t *,wchar_t)' :
overloaded
function differs only by return type from 'wchar_t *wcsrchr(const
wchar_t
*,wchar_t)'
include\string.h(47) : see declaration of 'wcsrchr'
C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE\wchar.h(1027) :
error C2373: 'wcsrchr' : redefinition; different type modifiers
include\string.h(47) : see declaration of 'wcsrchr'
C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE\wchar.h(1029) :
error C2556: 'const wchar_t *wcsstr(const wchar_t *,const wchar_t
*)' :
overloaded function differs only by return type from 'wchar_t
*wcsstr(const
wchar_t *,const wchar_t *)'
include\string.h(49) : see declaration of 'wcsstr'
C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE\wchar.h(1029) :
error C2373: 'wcsstr' : redefinition; different type modifiers
include\string.h(49) : see declaration of 'wcsstr'
C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE\wchar.h(1079) :
error
donation thank you - Hitomi Kimura
I would like to publicly thank Hitomi Kimura for his recent personal donation of US$500 to the OpenSSL project. He notes that he is a long time OpenSSL user and that for his job as an information security engineer in Japan he has distributed tens of thousands of client certificates. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Question about rationale for function X509_check_akid()
I'm using a verify callback function set via X509_STORE_set_verify_cb_func() to customize the behavior of X509_verify_cert(). For example errors related to the fact that no complete chain to a trusted root can be built are ignored, in order to still allow validation of other properties of signing certificates. When we have only a signing certificate without a chain and a CRL in the X509_STORE_CTX structure passed to X509_verify_cert(), this leads to the situation that the signing certificate is assumed to be the signer of the CRL in the store. The reason is the behavior of function X509_check_akid() in source file crypto/x509v3/v3_purp.c: int X509_check_akid(X509 *issuer, AUTHORITY_KEYID *akid) If I understand it correctly, the purpose of function X509_check_akid() is to test whether the issuer certificate matches the authority key identifier akid. If this is the case, the value X509_V_OK is returned, otherwise an error code is returned. What appears strange to me is that function X509_check_akid() only returns an error code if it actually finds a mismatch in one of the present attributes. If akid is a NULL pointer or if none of the comparisons is done because neither (akid-keyid issuer-skid), akid-serial or akid-issuer is true, the function returns X509_V_OK. Shouldn't it only return X509_V_OK if at least one of the three tests Check key ids (if present), Check serial number and Check issuer name actually was performed? Stephan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about rationale for function X509_check_akid()
On Wed, Apr 30, 2014 at 03:44:51PM +0200, Stephan M?hlstrasser wrote: Shouldn't it only return X509_V_OK if at least one of the three tests Check key ids (if present), Check serial number and Check issuer name actually was performed? Don't know about the CRL code path, but the same function is used in x509v3_cache_extensions() to determine whether a certificate is self-signed, where a missing akid means plausibly yes, provided the subject and issuer DNs are equal. This is also used in X509_check_issued() to verify the issuer-subject relations in a chain, but there the call is skipped when the subject akid is not set. The function is part of the public API (its name starts with an upper case X509 not x509 as with internal interfaces), so changing its semantics would introduce an incompatibility with applications that rely on the old behaviour. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
donation - Nokia, our first Platinum Sponsor
It is my great pleasure to announce that Nokia (http://company.nokia.com/en), formerly Nokia Solutions and Networks (NSN), has signed on as the first ever Platinum Sponsor of OpenSSL. Their press release: http://nsn.com/news-events/press-room/press-releases/nsn-makes-largest-donation-to-date-direct-to-the-openssl-project -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: donation - Nokia, our first Platinum Sponsor
Wow - congrats! Good and positive outcomes of Hearbleed : ) On Thu, May 1, 2014 at 12:52 AM, Steve Marquess marqu...@opensslfoundation.com wrote: It is my great pleasure to announce that Nokia (http://company.nokia.com/en), formerly Nokia Solutions and Networks (NSN), has signed on as the first ever Platinum Sponsor of OpenSSL. Their press release: http://nsn.com/news-events/press-room/press-releases/nsn-makes-largest-donation-to-date-direct-to-the-openssl-project -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
