Re: SSL_CTX_set_alpn_select_cb and Other OpenSSL API ALPN Functions + Their Callbacks
> While this may be reasonable advice for SNI, I'm not sure that > this is correct for ALPN. I don't think it is actually possible > to set the selected ALPN *without* using the ALPN callback. At > least I can't see a way. Correct, I wondered why I still used both callbacks. But I also know from experience you can not change SSL_CTX in the ALPN callback, it's too late in the handshake process. So if you need to change CTX, for instance for ALPN acme-tls/1 for Let's Encrypt, you have to do it during the HELO callback. > A useful addition to OpenSSL might be a new API to set the > selected ALPN directly which could be called from a client_hello_cb. Indeed, would save using two callbacks. Angus
Re: SSL_CTX_set_alpn_select_cb and Other OpenSSL API ALPN Functions + Their Callbacks
> I don't understand how to write the callback functions some of > the OpenSSL ALPN functions expect, and the manual really isn't > helping there either, so I'd like some help. Use SSL_CTX_set_client_hello_cb to set a SSL_client_hello_cb_fn function, which you can parse to get TLSEXT_TYPE_server_name and TLSEXT_TYPE_application_layer_protocol_negotiation, and everything else sent in the Client Hello (if you need it) like SSL versions and ciphers supported. Within this callback you can change SSL_CTX depending on SNI and ALPN. Ignore the SNI and ALPN callbacks. client_hello_cb was only added in 1.1.1 so is often missing from old examples, FAQs and manuals. Angus
RE: using TLS (>1.2) with more than one certificate
>> I_ve a server application and need to support RSA and ECC >> clients at the same time. > > Configure the server's SSL_CTX with both certificate chains and > the private keys for the two entity certificates, and for older > TLS versions the server will select the appropriate chain based > on the cipher-suite list in the ClientHello. Side tracking slightly, I have only ECC certificates on my web, mail and FTP servers, and SSL Labs says the only browser that can not connect to them is Chrome 49 on Windows XP SP3. Is there another reason I should be duplicating all my ECC certificates with RSA versions? I do see a lot of SSL connection errors in my logs, but assume these are mostly hackers or trackers with software not able to support TLS/1.2, usually with a blank SNI and ALPN and often no extensions in the client hello. One had 'Versions: TLSv1.1, TLSv1.3 Key Share Data' so got unsupported protocol. error:0A000102:SSL routines::unsupported protocol error:0A000418:SSL routines::tlsv1 alert unknown ca error:0AC1:SSL routines::no shared cipher error:0A6C:SSL routines::bad key share error:0A000413:SSL routines::sslv3 alert unsupported certificate Also lots of unexpected closes during handshake, and HTTP requests with no handshake. Angus
Re: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate )
> Yes. To make things even more complex, a few sites also have an > older version of R3 that is directly signed by the DST root: > > - leaf <- R3 <- DST Root CA X3 (self-signed) > > but that's far from common at this point. That old R3 root was issued last winter and got installed in Windows Server 2018 intermediate stores then, and was still being sent out on 29th and 30th, despite expiring on 29th. Perhaps because IIS caches server certificates. I had to delete it from the Windows store and reboot the server to stop it being sent out by IIS. Angus
Re: RSA provider use example
> I would like to see how the RSA* context parameter is filled in > and used, but I can't find an example using the RSA provider. This is an example I just created by building a OSSL_PARAM array with OSSL_PARAM_construct_xx and calling EVP_PKEY_get_params. I've been wondering if this is more efficient than getting the parameters one at a time using multiple EVP_PKEY_get_xx_param which also calls EVP_PKEY_get_params. I've removed trailing nulls from the unsigned integer fields where the returned data size is always the buffer size. RSA Key Parameters: Param Key: bits, type: Integer, len: 4 = 2048 Param Key: security-bits, type: Integer, len: 4 = 112 Param Key: max-size, type: Integer, len: 4 = 256 Param Key: e, type: UInteger, len: 1024 = 01000100 Param Key: n, type: UInteger, len: 1024 = CBE73B4395545CA90A5CE459EEDE322D0F8EFCA775C641626CE156C82B4482F3AAEA048A 73AD41A55F95FA330C858473D2A5C9F1AE771D2B9FE41B43178CFDCBC952725AFD06DA27 6F1F5298B8DE5E08F9DED442B57798A01DE09746FDF3ED920385AADDAFD391139595F3F1 37BD4DADE7F43FBA65BFF9EC4CBCF1A7A7A43D53183CE057797A60B28F326569C3B56B06 F7FD4FF310DA44AC1FFC1E81FA2480CCA9265D14AA99B0956A7ECBDAE94151E95D73ED67 2AC2BC654DA516D3A9F5C5C9CFC51B41EFC05A232AA40700C64A2DBD3D0EBFFE33BC0157 8FFB6E8CE06B28D448E2E18C42982A1DD2C73BB7D8B0A8B79DE20128586283036C03FD26 497BEE92 Param Key: d, type: UInteger, len: 1024 = 91ED9788089647F342094199DDF8097801CD30866D19E854649D16B5585311DDDC015AEB 7885AF558084A88911D00FF9315A5C943136655B91F11886970A9508176C3F1325E0D4B4 E7C6D4B44FEE74B96F1C42E0C40367A6213D74D9391AB01825F68A5F3D2A78241B600089 B3FF68D9DA2BA7D14E6F96255AAEB0A2906C22AA85308EC17DD4372A622C908D2ECB0A9E AA55773BE7C3C60D794D2E8628C71E95CB18A689BAB0385A20A5220521B71B1B5FB17A2D E47C8AEE7088B594B41A0C2A84DE0283CC72C96145761F7CE66768B004991B6F1725DF19 951A12C70DFDDAF36FBE9A8D218E085E8E69B604FE9772617A5E0721937626F6339A4A74 5C5DAB06 Param Key: rsa-factor1, type: UInteger, len: 1024 = 8D2CBBDD31C6B7F88AFAC5F935DF5CED43D83D296B5B389B1CC2CE741C217594F64490D0 D904D433AEBC4572240B6BD4D5B0C69AC96FC561447D759E97DA80CF07B5D559EF85 84445221EB20599FCD0B2236DCA7786DD7CAB1FB1AA9A6B8DE1AB80E74201CF27BEC1479 542945632114590E1FA160FFC4833B0E2122CCBE Param Key: rsa-factor2, type: UInteger, len: 1024 = B70BD9C4340422CD11A6443AF3B86E557B6EC0F4DA981CC25FB9DD7A8E548A794BC7775D 3EFC3EB91B242CA1C7925B8CE887B3817E3CE3B15F9C400E3710D29C62485413C76A8377 08E3708A7D9FDE29964F2C0893E74498B6330F9C15C7A235A60B37AFB4E397E3C16F4F5A F146CC2674F98C4D4CC079B4310BE85FA2C124C5 Param Key: rsa-exponent1, type: UInteger, len: 1024 = B9708BB779BA7984AB023E60FBD1263CBA4490D64ECFDE2C319FE29907F5F02B7570D181 2F3F3CEFEA1A9A9FCD2D9C373D74BB76CF709B3BEAB0879F61157550621C60B6A9F5 2D4E83A9B5DAE6B859DED1A775797BDB720F06A0FD9FF9B7F3EBEFD58CEC73B580EA67F6 8BFF385923EB6C0D06B8ED3867D902B36136A20F Param Key: rsa-exponent2, type: UInteger, len: 1024 = 152C82D495DD9CD6CF2327999B2B52C1F91BA352CDD2051CE8EE4D8EDE0D3C9B76B629AF EE1DC90A52CD5CC9B6B1A481CF549D1720A7DB59C89B13ABAC1677A50CB8814EE7F671B2 1D42F48AC74448738030278126FF8ABF06AC566FCF1F081BB72F9511202D06EF30A941FE 36660B4E9C745E0A1E5D66F6898A32226A9FC6B9 Param Key: rsa-coefficient1, type: UInteger, len: 1024 = 0C7F4DBEBAAEC38C0E636872F33803584AF8B00E7FF4799054A4C4BF56DB145D6914A4D8 9AB5C8F05C2794AC723BA26EF9E7FED4D3DFB6D710222A21EFA030C9A5E7175E36D072E7 74E1BB760BEF735672E3113A8D3F11BD227312A49077EDE7EC22D210972F8F28C832836B 58D414535641469B9D79378A16ACA582EC54BA3E Param Key: default-digest, type: String, len: 6 = SHA256 Total key parameters: 12 Angus
Re: EVP_DigestSignInit ECDSA P-256 SHA-256
> I am implementing a JWS based specification using openSSL. My > code is below, in pascal. I'm trying to reproduce this test case > here: https://datatracker.ietf.org/doc/html/rfc7515#appendix-A.3.1 > > I get a different outcome from EVP_DigestSignInit / > EVP_DigestUpdate / You could compare your result with our Delphi JWS implementation: https://svn.overbyte.be/svn/ics/trunk/Source/OverbyteIcsSslJose.pas there is an sample app that exercises all the functions. Beware the code is changing shortly since all the RSA_ and EC_ functions are deprecated in OpenSSL 3.0. Angus
Re: OpenSSL Beta 2, report of successful migration
> For JWS signing in relation to Letsencrypt (my use case for this > - mKey is a RSA keypair in EVP_PKEY*): My RSA signing is accepted fine by Let's Encrypt, it's trying to use ECDSA keys that fails, despite OpenSSL verifying my JWS signing as ok. Failed to Create Account: urn:ietf:params:acme:error:malformed, JWS verification error But since RSA works, not spent much time looking at it. Angus
Re: OpenSSL Beta 2, report of successful migration
> > Not looked at replacing low level RSA and EC APIs yet. > > We forced ourselves down that path because we had an internal > policy to only build OpenSSL toolkit with 'no-deprecated' Know I have to do it, but only really use low level stuff to build Json Web Keys, and the EC keys I build for signing seen incompatible with some servers, so really needs deeper investigation. Angus
Re: OpenSSL Beta 2, report of successful migration
> Just wanted to report that our private code update to move on > from OpenSSL 1.1.1 to 3.0 Beta 2 is successful. Likewise, I've updated our Windows code to use 3.0 easily, been running one public web server for three weeks. Only frustration has been the change of PKCS12 password encryption to AES256 from 3DES, since Microsoft only added AES256 support in October 2017 and older versions of Windows can only install PKCS12 3DES encrypted files, which requires the OpenSSL 3.0 legacy provider to be loaded. I believe the earliest versions of Windows to support AES256 are Windows Server 2016 v1709 and Windows 10 v1709. Also the legacy.dll does not load automatically from the same path as the main DLLs, but needs OSSL_PROVIDER_set_default_search_path to be set first. Not looked at replacing low level RSA and EC APIs yet. Angus
Re: Project direction
> The idea being that supporting existing users means not changing > the existing API, whereas catering to new users means working > towards a new fresh consistent API. OpenSSL has been in use for getting on for 20 years (I think) and may still be in use in another 20 years, so can not stay still to make life easy for old projects, it has to evolve for new projects, as it does. But any changes should be clearly documented and should not require the use of third party sites like ABI to discover new APIs and changes to old ones. Major changes are usually in the changelog, but can be hard to find when updating from a much earlier release. There should really be detailed articles about upgrading from any long term release to the latest release, with simple lists of all exports or macros removed or added, or whose use has changed. Also, there is an assumption OpenSSL is only used by other C developers, by the use of public macros that are not usable in any other language. BoringSSL replaced macros with exports and OpenSSL should consider doing the same. Currently changing a macro to an export is rarely documented, so it's hard for those that have rewritten macros in other languages to know something will be broken. There needs to be more task oriented documentation, for instance collecting the APIs needed to create a CSR or certificate, using APIs rather than command line tools which is where much of the documentation currently resides. For instance there is no documentation about building a stack of extensions to add SANs to requests and certificates so a lot of research is needed to adds SANs to a certificate. Angus
New NID for acmeIdentifier
Is it possible for a new NID and object to be added to support creating
and checking the Let's Encrypt ACME TLS-ALPN-01 challenge in which a
temporary X509 certificate is created with a specific X509v3 extension
containing shared information.
Currently, I get a new NID with:
OBJ_create('1.3.6.1.5.5.7.1.31','acmeIdentifier','X509v3 ACME
Identifier')
Angus
Re: [EXTERNAL] Re: Unusual certificates
> The second certificate seems garbaged at the 4th RDN of the > issuerName. > The Base64 edition might have added or deleted some characters. Sorry, looks like my manual word wrapping lost a character: -BEGIN CERTIFICATE- MIIHbDCCBVSgAwIBAgIIO7L2MrGOOTMwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ MBcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAyMjQyMzAwMDBaFw0yMTAy MjMyMzAwMDBaMHUxCzAJBgNVBAYTAlBMMRAwDgYDVQQEDAdTa2ltaW5hMRcwFQYD VQQqDA5KYWNlayBXb2pjaWVjaDEaMBgGA1UEBRMRUE5PUEwtNzQwNjAyMDgyMTQx HzAdBgNVBAMMFkphY2VrIFdvamNpZWNoIFNraW1pbmEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDbTjEdIL21ctkfJ88d7EQDegNo5VLyPQXNSp5emoNI Uf/y+RiL47SrWxS/hqYLGLUlItMsA+VCyP/+Oi42nRXcsJrSZdVgqhZTaWTZca8m FOeujXy9eVvnAlnDDeofC5zAxYoW4fQI1/aPwmJ437bHWa6NR0iXT9j0caYfK8vr P+gLlakBJA5RV42mt4CBZMSiNNhA9KMi9UNbtqSzlPEpSJn8Vo2LWUe+yIlUcbCD gaQ5EVi8K7U0j5BLVQfVparZGi7C50V1ZPwWsYlu7v1PKHMDXPwUzOlwZ//UrxdR nv/AFgjLjxuS+FNvCOaiyr0EmxccLKFvqycvx6qOxFulAgMBAAGjggLyMIIC7jCB 2wYIKwYBBQUHAQMEgc4wgcswCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5G AQQwfAYGBACORgEFMHIwNhYwaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0 b3JpdW0vUUNBMV9QRFMucGRmEwJFTjA4FjJodHRwOi8vd3d3LnNpZ2lsbHVtLnBs L3JlcG96eXRvcml1bS9RQ0ExX1BEU1BMLnBkZhMCUEwwFQYIKwYBBQUHCwIwCQYH BACL7EkBATATBgYEAI5GAQYwCQYHBACORgEGATBzBggrBgEFBQcBAQRnMGUwPgYI KwYBBQUHMAKGMmh0dHA6Ly9yZXBvLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9x Y2ExXzIwMTcuY2VyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zaWdpbGx1bS5w bDAdBgNVHQ4EFgQUVjnQyGMfM0fhHUvao3qe2tB5ZAMwCQYDVR0TBAIwADAfBgNV HSMEGDAWgBRC+k+GNoGdKKGeLRq1ULuqJ/KctDCB+QYDVR0gBIHxMIHuMIHrBgoq hGgBhvg9AAADMIHcMIHZBggrBgEFBQcCAjCBzAyByUt3YWxpZmlrb3dhbnkgY2Vy dHlmaWthdCBwb2RwaXN1IGVsZWt0cm9uaWN6bmVnbyBwb3dzdGHFgiB3IG9wYXJj aXUgbyBQb2xpdHlrxJkgVXPFgnVnIFphdWZhbmlhIENVWiBTaWdpbGx1bS4gVHJl xZvEhyBQb2xpdHlraSBDVVogU2lnaWxsdW0gem5hamR1amUgc2nEmSBwb2QgYWRy ZXNlbSBodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bTBCBgNVHR8E OzA5MDegNaAzhjFodHRwOi8vY3JsLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9x Y2ExXzIwMTcuY3JsMA4GA1UdDwEB/wQEAwIGQDANBgkqhkiG9w0BAQsFAAOCAgEA Jfef0HktjHsgL403s8XQggtqporvp5w2sZcQ+jCPb3h3xrztTjiUbIhw97No7u5J 5LV4pNuczzBynJYBeGQpYG/Tr37HNoCdQ+I8QfllF37O7MwCNWYbmenFjINIHogQ utizdHRIUDP5FY+3ZmTG0ZGz4Yi0Bw+6IEvLZM8SF7Ula9Bkyu/oF5SAN/h/f0t5 3PHIkqsiWG7xRUl9aBgyO8Q72r1tiY1aqfT665nRrOewXQHik9h1Fd/XwWtYZpnG hws8lFKGB/Dfa8BpXpx3hWdVgeUA75Spszt0Pcb0pCJyQ2x3F4VnphGv6p31VN5i d7M+nd3kUYuKHFjxVBWgiVlgeKrCD+wvM/jqNncW6ti6uXaeLM2WBI0FpLuT5ZD2 G5gtLZ8z3wI5BZsp07gl3ARD8EybcJVmVhxpfAcBgOTCoyhGbPKYIS0fmYYCzwFL St+I497avrAQtgDqDcCs1WlZWHts4dUudUJ8rV8uKgtVQUu0HofUZPjNPD8dJw6n 3YrVdsLleXQXKAJZCgti56lH+6eCsVs7fUNPAhnu3AHWvsBwFs/3DM3OBBXX5jtn 8miSC46ndNiq2hIsq+cvfVM4Qw57XDYgLWaINhI0QhluUqOAEDJmYitnesTfs3Ih /CCHBWG9Yw6XkaBk8TCks/OOuo9B9PFGt5wRasty/Ls= -END CERTIFICATE- This now reads correctly with OpenSSL. So the real error here was that sometimes OpenSSL accepts unwrapped base64, and sometimes not, but asn1parse never accepts it. Angus
Re: Unusual certificates
More information, the original certificates supplied by the end user had unwrapped base64 blocks, lines 2,500 long. I wrapped them for email. If I try the asn1parse command on the wrapped certificates, they now attempt to parse, the OK is fine, the bad one now gives an error message from asn1parse: Error in encoding 20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:crypto\asn1\asn1_lib.c:91: and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode from PEM_read_bio_X509. The RFC says 'Parsers MAY handle other line sizes' but it would be good if OpenSSL gave a 'PEM line too long' error rather than no error. I'll change my library code to check for line ending in the base64 to give the user a polite message. Now the only problem is what is asn1 decoding unhappy with? Angus
Unusual certificates
A client is having problems reading Polish Centum issued personal certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier, mostly. Using PEM_read_bio_X509 with some of these certificates says error::lib(0):func(0):reason(0), while the X509 command line tool says 'unable to load certificate'. Some certificates work with both methods. Using the asn1parse command from any version of OpenSSL says 'Error: offset out of range', while a Javascript based web tool is able to decode the ASN1, but is perhaps more tolerant of errors. So it seems there is something in the creation of these certificates that OpenSSL has never liked, but until 1.1.1 was tolerated sufficiently to allow them to be read. This certificate reads OK in 1.1.1 but fails asn1parse: -BEGIN CERTIFICATE- MIIHXjCCBUagAwIBAgIIbBjyWVjJUvcwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ MBcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAzMTkwODUxMDBaFw0yMTAz MTgwODUxMDBaMGcxCzAJBgNVBAYTAlBMMREwDwYDVQQEDAhEWklFRFpJQzEPMA0G A1UEKgwGUkFGQcWBMRowGAYDVQQFExFQTk9QTC03NDExMDMwMDQ3MTEYMBYGA1UE AwwPUkFGQcWBIERaSUVEWklDMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAm94BNi+bv2+oUKzN27GV0+95sm1AuDKdiKw7M63HcnjL+YYLoQvhleD7KlZR 7ntZfJ05vpWpQWM0Pt54M1Y8sJQObg+tUDlulVi7nADOrUNb3Tgctq1vbou3OpIp xaQUtC9qNpQbGXkgJRr09/nh5h09n4vgsvtS6cKlFfMe/o6xtUeWPYm+oVoAq5sG in+aBSBdnd73v053kbdZcbDPXmOYuCr6O2MHi7p+McPg2KMJy+wfFX4SGSBJIAY2 Owt6mnIOCU6Y/dAUcbUDtNUTwq+gXL+zg7TdwkDDTohpnluNGfrYV5JYocHO63zo 3W/CyF/enCmNiC9QLakA22O04QIDAQABo4IC8jCCAu4wgdsGCCsGAQUFBwEDBIHO MIHLMAgGBgQAjkYBATALBgYEAI5GAQMCAQowCAYGBACORgEEMHwGBgQAjkYBBTBy MDYWMGh0dHA6Ly93d3cuc2lnaWxsdW0ucGwvcmVwb3p5dG9yaXVtL1FDQTFfUERT LnBkZhMCRU4wOBYyaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0v UUNBMV9QRFNQTC5wZGYTAlBMMBUGCCsGAQUFBwsCMAkGBwQAi+xJAQEwEwYGBACO RgEGMAkGBwQAjkYBBgEwcwYIKwYBBQUHAQEEZzBlMD4GCCsGAQUFBzAChjJodHRw Oi8vcmVwby5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0vcWNhMV8yMDE3LmNlcjAj BggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2lnaWxsdW0ucGwwHQYDVR0OBBYEFDFY 5Q2FMMXaCpCyXFmUT2qgyA0JMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUQvpPhjaB nSihni0atVC7qifynLQwgfkGA1UdIASB8TCB7jCB6wYKKoRoAYb4PQAAAzCB3DCB 2QYIKwYBBQUHAgIwgcwMgclLd2FsaWZpa293YW55IGNlcnR5ZmlrYXQgcG9kcGlz dSBlbGVrdHJvbmljem5lZ28gcG93c3RhxYIgdyBvcGFyY2l1IG8gUG9saXR5a8SZ IFVzxYJ1ZyBaYXVmYW5pYSBDVVogU2lnaWxsdW0uIFRyZcWbxIcgUG9saXR5a2kg Q1VaIFNpZ2lsbHVtIHpuYWpkdWplIHNpxJkgcG9kIGFkcmVzZW0gaHR0cDovL3d3 dy5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0wQgYDVR0fBDswOTA3oDWgM4YxaHR0 cDovL2NybC5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0vcWNhMV8yMDE3LmNybDAO BgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggIBACQ+ancYPWmfVDB/PTrV D+nK8TX2HPcbgk/JrGJF0vaL+l9gTprg+3yMlfpcQfBXBsm7RwOEAK8LgaaFb7Ta WPD1635RoGaIZ36k6WgENUjFjANya3RIRSzcOjgpeQWc6SeA++NJjQFNh7J73LMG V5udFwpVug5yzP+LTlZZ/hoY2rN9xmY7QBn/cbgoNieRyUHbxq4zGifiJoVfKEiT Fxl/CoUfnngxsVIsvgxFmGdnMT2j0oBODKoXJ1A8oJAcg8KnYTzI7Dnt3a5cGypv n6V6tGv0IbHxdFu8nnsyNOSp1YhqTcfRzUGXf9NHyj6vyX4UR2ODJPccWC0uSufW 9KYio228yqj0IERG2mr8huJEBW/MEE3STmxT3R6a1OCAsVAPi3gL2yAXfn3Gdiam MLhj/WO3OD9OyiHqTY6+/md4vOHkHy7GnKlYIJblddtziv8ek9uH/imbOQIKDjLN Bvw3j9a55GHT/8+fow2vn31OmSfMWvikP4pntEvuMAwG2laTs19+gWdknt4Q3ma5 NTf9UnbQsFJAcW+gw3QWAmts5fZsQT806OyDvjt6jRlkmuIkeYRcYJ/E2Pg9oKx3 RiCIA1BQTImpYvbTJg9Q1DYQpbDGxDB9ENJDAyMNSIs85nBLvrri4rD6FC4Bz/m/ Og4GfIWH02DKEKBds/zPi+L5 -END CERTIFICATE- This certificate can not be read in 1.1.1 but is OK in 1.1.0. -BEGIN CERTIFICATE- MIIHbDCCBVSgAwIBAgIIO7L2MrGOOTMwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ BcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAyMjQyMzAwMDBaFw0yMTAyM jMyMzAwMDBaMHUxCzAJBgNVBAYTAlBMMRAwDgYDVQQEDAdTa2ltaW5hMRcwFQYDV QQqDA5KYWNlayBXb2pjaWVjaDEaMBgGA1UEBRMRUE5PUEwtNzQwNjAyMDgyMTQxH zAdBgNVBAMMFkphY2VrIFdvamNpZWNoIFNraW1pbmEwggEiMA0GCSqGSIb3DQEBA QUAA4IBDwAwggEKAoIBAQDbTjEdIL21ctkfJ88d7EQDegNo5VLyPQXNSp5emoNIU f/y+RiL47SrWxS/hqYLGLUlItMsA+VCyP/+Oi42nRXcsJrSZdVgqhZTaWTZca8mF OeujXy9eVvnAlnDDeofC5zAxYoW4fQI1/aPwmJ437bHWa6NR0iXT9j0caYfK8vrP +gLlakBJA5RV42mt4CBZMSiNNhA9KMi9UNbtqSzlPEpSJn8Vo2LWUe+yIlUcbCDg aQ5EVi8K7U0j5BLVQfVparZGi7C50V1ZPwWsYlu7v1PKHMDXPwUzOlwZ//UrxdRn v/AFgjLjxuS+FNvCOaiyr0EmxccLKFvqycvx6qOxFulAgMBAAGjggLyMIIC7jCB2 wYIKwYBBQUHAQMEgc4wgcswCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5GA QQwfAYGBACORgEFMHIwNhYwaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0b 3JpdW0vUUNBMV9QRFMucGRmEwJFTjA4FjJodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL 3JlcG96eXRvcml1bS9RQ0ExX1BEU1BMLnBkZhMCUEwwFQYIKwYBBQUHCwIwCQYHB ACL7EkBATATBgYEAI5GAQYwCQYHBACORgEGATBzBggrBgEFBQcBAQRnMGUwPgYIK wYBBQUHMAKGMmh0dHA6Ly9yZXBvLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9xY 2ExXzIwMTcuY2VyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zaWdpbGx1bS5wb DAdBgNVHQ4EFgQUVjnQyGMfM0fhHUvao3qe2tB5ZAMwCQYDVR0TBAIwADAfBgNVH SMEGDAWgBRC+k+GNoGdKKGeLRq1ULuqJ/KctDCB+QYDVR0gBIHxMIHuMIHrBgoqh GgBhvg9AAADMIHcMIHZBggrBgEFBQcCAjCBzAyByUt3YWxpZmlrb3dhbnkgY2Vyd
Cleanup of the EC API
If possible, a EC_KEY_get_public_key_affine_coordinates function would be appreciated, so we can avoid using EC_POINT_get_affine_coordinates_GFp. Unless I've missed a better function to get raw x/y. Perhaps also EC_KEY_get_curve_name? Angus
Re: Handshake failure: TLSv1.3 early data?
> error:140E0197:SSL routines:SSL_shutdown:shutdown while in init, > State: SSL negotiation finished successfully And lots more similar overnight: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init, State: TLSv1.3 early data It seems some browsers open three to five sockets at the same time and then don't complete SSL negotiation on all of them, just closing them in various states. So not really negotiation failures. Angus
Re: Handshake failure: TLSv1.3 early data?
> Is it possible the browsers are trying to send early data? I doubt it, I was not reporting the error, trying to report errors before they disappear with clean-up code is an art, and does not always work, so mostly I now see: error::lib(0):func(0):reason(0), State: TLSv1.3 early data, connection closed unexpectedly but sometimes error:140E0197:SSL routines:SSL_shutdown:shutdown while in init, State: SSL negotiation finished successfully But only four failures are logged on the live server so far, there will be more handshake failures overnight that might be more helpful. Suspect the real issue is simply the client abandoning the connection, and different places leave different errors. Some failures are obvious like TLSv1 which is disabled on the server. But I was worried our TLSv1.3 implementation was missing something important. Read a lot about early data, but not really why anyone uses it in practice, if it is used. Quite content to continue to ignore early data. Angus
Re: Handshake failure: TLSv1.3 early data?
> > My public web servers shows several handshake failures daily > > due to 'TLSv1.3 early data', sometimes after a previous > > successful TLSv1.3 connection, but not always. > > Do you have specific error messages? I seem to only report the state rather than an error once the socket is closed, take a few hours to get some more failures with real errors. Angus
Handshake failure: TLSv1.3 early data?
My public web servers shows several handshake failures daily due to 'TLSv1.3 early data', sometimes after a previous successful TLSv1.3 connection, but not always. I'm not currently attempting to handle any early data, I thought it was disabled by default. Is there something I should be doing like using SSL_CTX_set_allow_early_data_cb() to reject the early data? Or setting SSL_CTX_set_recv_max_early_data() to zero? Maybe these errors are the result of bad client implementations and I should just ignore them. Like all public servers, there are thousands of hacking attempts daily, and other silly accesses, like why would anyone want to negotiate protocol 0x0103 while also sending the EC Group extension? Angus
Re: Json Web Keys again
> There isn't a key specific format for Ed25519. > You need to use i2d_PUBKEY() for that. I used EVP_PKEY_get_raw_public_key which got added for these raw keys, works fine for Ed25519. On the EVP_PKEY_get_raw_public_key.html page, it would help if it mentioned that *len should be set to the passed buffer size on the get_raw functions which fail if you pass zero. Angus
Re: Json Web Keys again
> > It seems the EVP_PKEY_RSA_PSS addition was only committed 28th > > October 2019, so need to wait for 1.1.1e, hopefully real soon... > > Ah, that explains it! Now tested with 1.1.1e-dev and I can generate a JWK from an RSA-PSS key. Since JWK is for signing, I also tried to support ED25519 private keys, but get: error:0D0A40A7:asn1 encoding routines:i2d_PublicKey:unsupported public key type A binary public key is all I need for JWK, simple format. A search of master suggests nothing yet. Angus
Re: Json Web Keys again
> > Agreed, code looks clear enough, but was this was for 1.1.1 or > > master? > > This code looks the same in 1.1.1 and master. It seems the EVP_PKEY_RSA_PSS addition was only committed 28th October 2019, so need to wait for 1.1.1e, hopefully real soon... RSA_get0_pss_params as well would be good. Thanks for your help. Angus
Re: Json Web Keys again
>> Sorry. My mistake. I actually meant what does EVP_PKEY_id()
> return.
Also returns 912, the same as base_id. RSA keys both return 6.
> So if you get EVP_PKEY_RSA_PSS returned from that I don't
> currently understand how this:
>
> RSA *EVP_PKEY_get0_RSA(const EVP_PKEY *pkey)
> {
> if (pkey->type != EVP_PKEY_RSA && pkey->type !=
> EVP_PKEY_RSA_PSS) {
> EVPerr(EVP_F_EVP_PKEY_GET0_RSA,
> EVP_R_EXPECTING_AN_RSA_KEY);
> return NULL;
> }
> return pkey->pkey.rsa;
> }
>
> Can return the error you saw!! Something strange going on...
Agreed, code looks clear enough, but was this was for 1.1.1 or master?
Just created a new RSA-PSS key with the latest OpenSSL and same error.
Angus
Re: Json Web Keys again
> What does EVP_PKEY_base_id() return for your pkey? How did you > create it? base_id is 912, EVP_PKEY_RSA_PSS=NID_rsassaPss. But my code is Pascal so not using your header files directly, seems okay though. It was created with OpenSSL APIs and EVP_PKEY_print_private reports: RSA-PSS Private-Key: (2048 bit, 2 primes) Angus
Re: Json Web Keys again
> > I create an RSA JWK using EVP_PKEY_get1_RSA and RSA_get0_key, > > but this does not work for RSA-PSS. > > In what way does this not work? error:0607907F:digital envelope routines: EVP_PKEY_get0_RSA:expecting an rsa key > I notice that 3.0 recently had the accessor RSA_get0_pss_params() > added. Probably that should also have been backported to 1.1.1. Others have asked for that here before, so please. But I don't need it for JWK. Angus
Json Web Keys again
Google has started using RSA-PSS private keys for Json Web Keys. I create an RSA JWK using EVP_PKEY_get1_RSA and RSA_get0_key, but this does not work for RSA-PSS. EVP_PKEY_print_private does work OK, but parsing data from the output is messy. EVP_PKEY_set_alias_type seemed worth a try, but does not set the base_id. Are there any other workarounds? Is RSA-PSS fully supported in 3.0? Angus
Re: OpenSSL 3.0 (or 4.0) API goals
> I'm curious if there's any consideration being given to updating > the API for existing interfaces, and/or checking the APIs of any new > interfaces for issues that are seen in the current API. Also replacing all C macros such as those for SSL_CTX_ctrl with proper external functions. This will ease use of OpenSSL with languages other than C, where we currently have to code functions to replace the macros. Google did this when creating BoringSSL, there may be other similar 'improvements' that could help OpenSSL. Angus
Re: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library
> The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for > binscope GSCheck on Windows. This must be a customised non-standard library, since 1.1.0 does not build with that name, but as libcrypto-1_1.dll. Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
> Some Chrome browsers seem to be hitting https://www.tls13.net/ > with versions from Chrome/70.0.3534.4 upwards to Chrome/71.0.3544.0 Some of my public web servers are now on yesterday's version, three TLSv1.3 users today, two with Firefox 63, one with Chrome/68.0.3440.106+Safari/537.36. I seem to be on Chromium Chrome/70.0.3538.9 and TLSv1.3 did not initially work, had to go to experimental flags to change from draft 28 and final and now it does work. Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
> IIUC, only Firefox nightly as of approximately today will support > the final RFC 8446 version; Firefox 63.0b5 works OK with OpenSSL 1.1.1, think it came Tuesday. https://download.mozilla.org/?product=firefox-beta-stub=win=en-U S > I haven't looked into Chrome yet. My versions don't work yet, but I might not be on the latest nightly stuff. Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves?
> Personally, I see this as a showstopper re a release on Tuesday, > but I think it's on all of us to come to an agreement, that is > unless we actually do label and fix everything that needs fixing > 'til Monday evening (Euro time)... The planned Tuesday release was only another beta, albeit perhaps the last. So even if the final 1.1.1 release is delayed, it would still be very useful to have an RFC compliant version of TLSv1.3 in a beta sooner rather than later, for final testing against browsers and clients. And then perhaps another final beta if lots of other stuff is changed? Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS 2.0.11 build with Visual Studio 2010 fails self-tests
> I hit the exactly the same issue as the one reported here - > http://openssl.6102.n7.nabble.com/FIPS-Module-1-2-build-with-Visua > l-Studio-2010-fails-self-tests-tt36372.html#a36391 > > Anybody knows if a solution is available now? That is an eight year old message for an obsolete OpenSSL version. There is a more current version OpenSSL v1.0.2m-fips binary for Win32 built with Visual Studio Community 2015, at: http://wiki.overbyte.eu/wiki/index.php/ICS_Download That does pass the self test. Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] ESNI in 1.1.1?
Is there any way that Encrypted Server Name Indication will make the 1.1.1 release, or is too late or too experimental? Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to send alert in handshake?
> In order to implement SNI you need an SNI callback > The callback should return: > > SSL_TLSEXT_ERR_OK, if it successfully processed the SNI > SSL_TLSEXT_ERR_ALERT_WARNING, to send a warning alert back > SSL_TLSEXT_ERR_ALERT_FATAL, to send a fatal alert back > SSL_TLSEXT_ERR_NOACK, to continue without acknowledging the SNI > at all Our SSL library used to return SSL_TLSEXT_ERR_ALERT_WARNING if no name match was found, until we discovered that Java SSL treats this as a fatal error when we changed to OK. But it did not seem to cause a problem with any browsers or OpenSSL clients, which I assume ignore it. What would SSL_alert_type_string return in the client? Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Confused about client side session caching
> The get_session_cb is only ever called for servers. The > new_sesion_cb and remove_session_cb can be called for clients and > servers. > > When you refer to the the "TLSv1.3 notes" do you mean this page? > https://wiki.openssl.org/index.php/TLS1.3 Yes, sorry I should have said SSL_CTX_sess_set_new_cb not set_get_cb. > I think new_session_cb and remove_session_cb should work in 1.0.2 > on clients. Good, that ties in with my testing, just not with the notes where you said it worked for clients in 1.1.0, suggesting it might have been introduced then. Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Confused about client side session caching
I'm reading the TLSv1.3 notes that suggest SSL_CTX_sess_set_get_cb is called for both clients and servers, but am confused by the documentation. The 1.1.1 manual page still starts 'provide callback functions for server side external session caching' with no mention of clients. I'm updating code that supports 1.0.2 to 1.1.1 for external session caching, for clients and servers, so particularly interested when client session callbacks arrived. The TLSv1.3 notes suggest the callback worked for clients in 1.1.0, a quick test suggests it actually gets called in 1.0.2 as well. Is this correct? Has OpenSSL internal session caching improved over the years so that external caching is no longer necessary? Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows 1.1.1 binaries and web server
> This is very useful! Can you post an udate to the wiki? > https://wiki.openssl.org/index.php/Binaries Wiki has been updated with details of the binaries and download locations. Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [wiki-support] Wiki
Subject:* Re: [openssl-users] Windows 1.1.1 binaries and web server *From:* "Salz, Rich" <rs...@akamai.com> *To:* "an...@magsys.co.uk" <an...@magsys.co.uk>, "openssl-users@openssl.org" <openssl-users@openssl.org> *Date:* Wed, 21 Feb 2018 14:12:25 + This is very useful! Can you post an udate to the wiki? https://wiki.openssl.org/index.php/Binaries Original Message *Subject:* Re: [wiki-support] Wiki *From:* Matt Caswell <m...@openssl.org> *To:* wiki-supp...@openssl.org, an...@magsys.co.uk *Date:* Thu, 22 Feb 2018 15:48:41 + On 21/02/18 17:31, Angus Robertson - Magenta Systems Ltd wrote: > Can I please have an account on the wiki, I'm already on the mailing > lists. Hi Angus Please could you some examples of changes that you wish to make on the wiki? Please be specific. Also, what username would you like? Regards Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Windows 1.1.1 binaries and web server
Windows developers may be interested in our Win32 build of OpenSSL 1.1.1-pre1 (alpha), the binaries are digitally code signed 'Open Source Developer, François PIETTE', the lead developer for the Delphi Internet Component Suite project. About half way down the page at: http://wiki.overbyte.eu/wiki/index.php/ICS_Download The latest 1.0.2 and 1.1.0 are also available, digitally code signed. I have also built my Windows ICS web application server to use 1.1.1-pre1 (alpha) so it can be used for testing TLSv1.3, the information page shows the protocol you connect with, the ciphers available and the OpenSSL and draft version being used. Currently most browsers still connect with TLSv1.2. https://www2.telecom-tariffs.co.uk/serverinfo.htm Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Creating a Json Web Key
> > If there an equivalent for EC_GROUP to get x and y? > > Do you mean for an EC_POINT? If so then: > EC_POINT_get_affine_coordinates_GFp() or Thanks, JKW now built for both key types in 1.1.0. I guess my function would be useful to others as EVP_PKEY_to_JWK_bio or something, unfortunately it's not written in C, but pascal. Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Creating a Json Web Key
>> I've not yet found any helpers for getting n and e any other way. > RSA_get0_key()? Perfect, should have been able to find that myself... If there an equivalent for EC_GROUP to get x and y? Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Creating a Json Web Key
I need to create a Jose JWK from the public part of a private key in a PEVP_PKEY, with 1.1.0. I've done it using the old struct rsa_st from 1.0.2 and EVP_PKEY_get1_RSA, and then converting the n and e BIGNUMs to binary (and then to Base64Url). This still works in 1.1.0 although rsa_st has more stuff after n and e, but obviously is not ideal. I've not yet found any helpers for getting n and e any other way. Is there a better way to build a JWK? Now need to handle elliptic curve keys as well. Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Upgrading to 1.1.1
I'm updating our Delphi SSL code to support 1.1.1 in addition to 1.0.2 and 1.1.0, common code with a few version checks. This is using Windows 10. With 1.1.1, SSL connections fail to initialise, failing with the first BIO_read after setting up the context and BIOs. There is no real error (I can see), read just fails and BIO_should_retry says no with a zero reason. We are using SSL filter I/O with a BIO pair, we handle all I/O using non-blocking Windows APIs. There was no particular issue updating to 1.1.0, apart from new context stuff, but 1.1.1 seems to have changed something to make our code fail. I can not see anything in the TLS/1.3 notes that relates to simple SSL initialisation. The main APIs called are, in order: SSL_new(myContext) BIO_new(BIO_f_ssl) BIO_new_bio_pair SSL_set_ex_data SSL_set_session SSL_set_tlsext_host_name SSL_set_connect_state SSL_set_bio SSL_set_info_callback SSL_set_msg_callback BIO_set_ssl BIO_read - 0 bytes which is where it dies, after a SSL_CB_HANDSHAKE_START info message and a 512 byte write client hello. The openssl.exe built with 1.1.1 seems to work OK making a client connection, but uses different BIO I/O. Is some new initialisation required for 1.1.1? Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Creating requests and certificates with Subject Alternative Names
I'm creating X509 certificate requests and certificates in code, trying to add X509v3 Subject Alternative Name, with 1.1.0f. But if I add a list of four domains, ie: www1.mydomain www2.mydomain www3.mydomain www4.mydomain The certificate seems to ignore some and repeat others: X509v3 Subject Alternative Name: DNS:www3.mydomain, DNS:www4.mydomain, DNS:www3.mydomain, DNS:www4.mydomain Finding documentation for SANs in OpenSSL is very hard, there don't seem to be high level APIs to create extension content stacks. The best I found is set_altname in v3nametest.c which builds a stack of GENERAL_NAMES and adds it using X509_add1_ext_i2d. I must be something correct since it half works, but no idea why the data is corrupted. To complicate matters, I'm not writing in C, but using Delphi pascal, so all the OpenSSL APIs and macros have been converted to Delphi, which does potentially cause errors in translation. This is an open source Delphi interface to OpenSSL. Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
