Re: [openssl-users] stunnel 5.46 released
> On May 31, 2018, at 12:09 AM, Michal Trojnara > wrote: > > I respectfully disagree. The only practical disadvantage of kRSA is > that it doesn't provide PFS. Losing PFS is bad, but it's not a huge > price for ensuring secure key exchange. There's an assumption here that DHE key exchange is not secure, while ECDHE is secure. That assumption is wrong. Only export grade DHE was shown weak in logjam. OpenSSL no longer accepts weak DHE keys. There are also weak ECDSA curves that old implementations would accept, there nothing fundamentally better (performance aside) about ECDHE vs. DHE. Indeed some trust DHE more because the keys are larger and perhaps more resistant to QC, and the mathematics is better understood (less bleeding edge than elliptic curves). I expect there are still plenty of LTS RedHat systems that ship without EC support, though yes anything reasonably up to date, will have EC support. Ultimately of course up to you and your users, I think I've made my case as well as I could. Good luck. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] stunnel 5.46 released
On 30.05.2018 19:12, Viktor Dukhovni wrote: > So I would disable only kDH, but not DHE. Keep in mind that > some remote systems will not support EECDH, and by disabling > DHE, you get only kRSA, which is worse. So I think that > '!DH' is unwise. I respectfully disagree. The only practical disadvantage of kRSA is that it doesn't provide PFS. Losing PFS is bad, but it's not a huge price for ensuring secure key exchange. Actually, there aren't that many platforms nowadays that support kDHE and not kECDHE. Best regards, Mike signature.asc Description: OpenPGP digital signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Test SSL connection
> On May 30, 2018, at 4:06 PM, Jordan Brown > wrote: > > And also: the certificate is unlikely to list an IP address, so it should > fail hostname verification. You need to use a host name in your client > connection request, not an IP address. > > (Pretty much, you don't ever want to use IP addresses in specifying TLS > connections.) True, but s_client does not do namechecks by default. You'd have to request that behaviour with the "-verify_hostname" option. The OP does not report doing that, so verification was likely limited to just checking the trust chain. A more complete invocation (with 1.1.0 or later) would be: openssl s_client \ -connect $host:$port \ -CApath $capath \ -CAfile $cafile \ -verify $depth \ -servername $host \ -verify_hostname $host \ -verify_return_error for suitable choices of $capath, $cafile, $depth, $host and $port and in some cases additional desired options. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Test SSL connection
On 5/30/2018 1:16 AM, Walter H. wrote: > On 30.05.2018 08:45, Mark Shnaider via openssl-users wrote: >> [...] >> >> openssl s_client -connect 10.65.48.108:443 >> >> [...] > very probable, that the client doesn't have the root ca certificate of > the ca certificate that signed server.pem > > you should have at least the following > > ca.pem - the root ca > server.pem - the server ssl/tls certificate And also: the certificate is unlikely to list an IP address, so it should fail hostname verification. You need to use a host name in your client connection request, not an IP address. (Pretty much, you don't ever want to use IP addresses in specifying TLS connections.) -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
> Either way, trying to use OpenSSL's PRNGD to seed OpenSSL's PRNGD is an > exercise in futility. Oh, I agree on that. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] stunnel 5.46 released
> On May 30, 2018, at 12:54 PM, Michał Trojnara > wrote: > >> I am rather puzzled as to why you chose to eliminate >> not just fixed DH, but also the ephemeral finite-field >> DH key exchange. What's wrong with the DHE ciphers? > > Mostly precomputation attacks: https://weakdh.org/logjam.html Which is an issue with *weak* DH parameters, which are no longer accepted by OpenSSL. Ephemeral DH is in the majority of server implementations actually ephemeral. The group is fixed, but the server private key is per session, or with old unpatched code randomly chosen by each server. It is not clear to me that EECDH is fundamentally stronger. Indeed it might prove weak sooner to QC attacks if/when those become practical. So I would disable only kDH, but not DHE. Keep in mind that some remote systems will not support EECDH, and by disabling DHE, you get only kRSA, which is worse. So I think that '!DH' is unwise. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] stunnel 5.46 released
On 05/29/2018 01:48 AM, Viktor Dukhovni wrote: > I am rather puzzled as to why you chose to eliminate > not just fixed DH, but also the ephemeral finite-field > DH key exchange. What's wrong with the DHE ciphers? Mostly precomputation attacks: https://weakdh.org/logjam.html Those parameters are "ephemeral", but not really unique for each TLS session. They are also quite slow compared to their EC counterparts... > I would have chosen: > > HIGH:!aNULL:!kDH:!kECDH:!MD5 > > which excludes the *fixed* DH/ECDH ciphers and MD5 > (and thus also SSLv2). This does not eliminate > ephemeral finite-field DH, not sure why you're doing > that... Actually the only MD5 vulnerability is collisions. This may be a threat for some CAs that use predictable serial numbers, but there are no known risk for HMACs as used in TLS cipher suites. Also, excluding kECDH cipher suites sounds like a good idea indeed. Best regards, Mike -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
In message on Wed, 30 May 2018 15:37:47 +, Scott Neugroschl said: scott_n> The platform in question is an HPE NonStop. NonStop isn't the only platform with this sort of problem... I'd suggest asking in places dedicated to NonStop if they know of good enough ways to gather enough entropy, such as comp.sys.tandem, perhaps? Either way, trying to use OpenSSL's PRNGD to seed OpenSSL's PRNGD is an exercise in futility. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
> On 31 May 2018, at 1:35 AM, Michael Wojcik > wrote: > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> Of FooCrypt >> Sent: Wednesday, May 30, 2018 10:46 >> To: openssl-users@openssl.org >> Subject: Re: [openssl-users] PRNG is not seeded >> >>> On 30 May 2018, at 11:55 PM, Michael Wojcik >> wrote: >>> >>> Where would openssl rand be getting its entropy from, in this case? You >> have a circular dependency: openssl needs entropy, so it tries to get it from >> PRNGD; and you're asking openssl to put entropy into PRNGD. >>> >> >> Usage: rand [options] num > > Spare me, please. > >> RAND(1) describes the multiplicity of sources that can all be used together >> in >> some detail. > > And why do you think this solves the problem? Well its HP’s problem, not openssl’s > >> The rand command outputs num pseudo-random bytes after seeding the >> random number generator once. > > So all the entropy you can get from the output of "openssl rand" is whatever > OpenSSL was able to gather when it seeded the PRNG. Which is exactly the > problem Scott was trying to solve. > >> Make some .rnd’s > > YOU STILL HAVE TO FIND ENTROPY TO PUT IN THEM. All you're doing is pushing > the problem around the plate. generate them on another host > >> >> dd if=/dev/[SOMEDEVICE] of=~/.rnd bs=1 count=1024 > > Where [SOMEDEVICE] is your magical unicorn entropy device? well its not /dev/random, its a HPE NonStop with no entropy that stops the application. > >> Make an engine > > I already mentioned the engine interface in my previous response. And if this > is an option for Scott, it would be much better to use the engine in his > application, rather than going through the rigamarole of running "openssl > rand" to grab some entropy from it. The command-line utility is useful iff he > can't change the application. HPE NonStops don’t have DTrace > >> Microphones work wonders > > No, they really don't. Look at the literature. (And, again, I mentioned > sensors in my previous response.) > >> and you can play with the sound, count, >> etc….etc….etc... > > Cargo-cult entropy gathering. It may be fine under a given threat model, but > we have no idea what Scott's is. As general advice it's poor. Probably financial sector, with PCI compliance and they can;t afford /dev/random or /dev/urandom > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > > -- > 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] PRNG is not seeded
>>> I’m using PRNGD to seed my random numbers (I’m on a system without >>> /dev/random and /dev/urandom). I occasionally get the dreaded “PRNG is >>> not seeded” error. >> >> I don’t know your OS or environment, have you tried the ‘openssl rand’ >> functionality as a random source to seed your entropy issues ? > >Where would openssl rand be getting its entropy from, in this case? You have a >circular dependency: openssl needs entropy, so it tries to get it from PRNGD; >and you're asking openssl to put entropy into PRNGD. > >> perhaps rather than pseudo random, try a hardware device ? > >Now, this is a case where you might use openssl rand, in conjunction with >engine, to get entropy from another source. That could be a useful hack if you >can't easily change PRNGD or the application to read entropy from the device. > >For example, I think I successfully used openssl with the pkcs11 engine to get >entropy from a NitroKey device a couple of years back, when I was playing >around with cheap HSMs. > >Whether something like the NitroKey (which is an inexpensive USB-attached HSM >in a thumbdrive form factor) would be useful in this case is something Scott >would have to determine. > >If it is, it'd be cleaner if he could change the application to load the >pkcs11 engine and use its RNG directly, or at least get entropy from it to >seed OpenSSL's PRNG. > >>> I know this is caused by a lack of available entropy in the system; >>> but what can I do to address this? Is it just a matter of waiting >>> until enough entropy has been collected? Is there any kind of workaround? > >Depends on what sources PRNGD uses (I haven't looked), what the device is, >what the application is... If the device has sensors you can read, you might >be able to gather some entropy by reading noise from them (though this is >somewhat fraught - you don't want to overestimate the amount of entropy, and >both sensors and sensor APIs are often vulnerable to attack). > >Sometimes applications ask users to generate some entropy by asking them to >bang on the keyboard or wiggle the mouse, or that sort of thing. Again, it >really depends on what your device and application are. > >This topic is discussed at some length in the technical literature; see for >example section 3 of RFC 4086. > The platform in question is an HPE NonStop. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of FooCrypt > Sent: Wednesday, May 30, 2018 10:46 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] PRNG is not seeded > > > On 30 May 2018, at 11:55 PM, Michael Wojcik > wrote: > > > > Where would openssl rand be getting its entropy from, in this case? You > have a circular dependency: openssl needs entropy, so it tries to get it from > PRNGD; and you're asking openssl to put entropy into PRNGD. > > > > Usage: rand [options] num Spare me, please. > RAND(1) describes the multiplicity of sources that can all be used together in > some detail. And why do you think this solves the problem? >The rand command outputs num pseudo-random bytes after seeding the > random number generator once. So all the entropy you can get from the output of "openssl rand" is whatever OpenSSL was able to gather when it seeded the PRNG. Which is exactly the problem Scott was trying to solve. > Make some .rnd’s YOU STILL HAVE TO FIND ENTROPY TO PUT IN THEM. All you're doing is pushing the problem around the plate. > > dd if=/dev/[SOMEDEVICE] of=~/.rnd bs=1 count=1024 Where [SOMEDEVICE] is your magical unicorn entropy device? > Make an engine I already mentioned the engine interface in my previous response. And if this is an option for Scott, it would be much better to use the engine in his application, rather than going through the rigamarole of running "openssl rand" to grab some entropy from it. The command-line utility is useful iff he can't change the application. > Microphones work wonders No, they really don't. Look at the literature. (And, again, I mentioned sensors in my previous response.) > and you can play with the sound, count, > etc….etc….etc... Cargo-cult entropy gathering. It may be fine under a given threat model, but we have no idea what Scott's is. As general advice it's poor. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
> On 30 May 2018, at 11:55 PM, Michael Wojcik > wrote: > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> Of FooCrypt >> Sent: Tuesday, May 29, 2018 21:41 >> To: openssl-users@openssl.org >> Subject: Re: [openssl-users] PRNG is not seeded >> >>> On 30 May 2018, at 8:58 AM, Scott Neugroschl >> wrote: >>> >>> I’m using PRNGD to seed my random numbers (I’m on a system without >>> /dev/random and /dev/urandom). I occasionally get the dreaded “PRNG is >>> not seeded” error. >> >> I don’t know your OS or environment, have you tried the ‘openssl rand’ >> functionality as a random source to seed your entropy issues ? > > Where would openssl rand be getting its entropy from, in this case? You have > a circular dependency: openssl needs entropy, so it tries to get it from > PRNGD; and you're asking openssl to put entropy into PRNGD. > Usage: rand [options] num where options are -out file - write to file -engine e - use engine e, possibly a hardware device. -rand file:file:... - seed PRNG from files -base64 - base64 encode output -hex - hex encode output RAND(1) describes the multiplicity of sources that can all be used together in some detail. DESCRIPTION The rand command outputs num pseudo-random bytes after seeding the random number generator once. As in other openssl command line tools, PRNG seeding uses the file $HOME/.rnd or .rnd in addition to the files given in the -rand option. A new $HOME/.rnd or .rnd file will be written back if enough seeding was obtained from these sources. ls -la ~/.rnd -rw--- 1 X X 1024 30 May 10:45 .rnd Make some .rnd’s dd if=/dev/[SOMEDEVICE] of=~/.rnd bs=1 count=1024 Make an engine Microphones work wonders and you can play with the sound, count, etc….etc….etc... >> perhaps rather than pseudo random, try a hardware device ? > > Now, this is a case where you might use openssl rand, in conjunction with > engine, to get entropy from another source. That could be a useful hack if > you can't easily change PRNGD or the application to read entropy from the > device. > > For example, I think I successfully used openssl with the pkcs11 engine to > get entropy from a NitroKey device a couple of years back, when I was playing > around with cheap HSMs. > > Whether something like the NitroKey (which is an inexpensive USB-attached HSM > in a thumbdrive form factor) would be useful in this case is something Scott > would have to determine. > > If it is, it'd be cleaner if he could change the application to load the > pkcs11 engine and use its RNG directly, or at least get entropy from it to > seed OpenSSL's PRNG. > >>> I know this is caused by a lack of available entropy in the system; but what >>> can I do to address this? Is it just a matter of waiting until enough >>> entropy >>> has been collected? Is there any kind of workaround? > > Depends on what sources PRNGD uses (I haven't looked), what the device is, > what the application is... If the device has sensors you can read, you might > be able to gather some entropy by reading noise from them (though this is > somewhat fraught - you don't want to overestimate the amount of entropy, and > both sensors and sensor APIs are often vulnerable to attack). > > Sometimes applications ask users to generate some entropy by asking them to > bang on the keyboard or wiggle the mouse, or that sort of thing. Again, it > really depends on what your device and application are. > > This topic is discussed at some length in the technical literature; see for > example section 3 of RFC 4086. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > > -- > 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] PRNG is not seeded
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of FooCrypt > Sent: Tuesday, May 29, 2018 21:41 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] PRNG is not seeded > > > On 30 May 2018, at 8:58 AM, Scott Neugroschl > wrote: > > > > I’m using PRNGD to seed my random numbers (I’m on a system without > > /dev/random and /dev/urandom). I occasionally get the dreaded “PRNG is > > not seeded” error. > > I don’t know your OS or environment, have you tried the ‘openssl rand’ > functionality as a random source to seed your entropy issues ? Where would openssl rand be getting its entropy from, in this case? You have a circular dependency: openssl needs entropy, so it tries to get it from PRNGD; and you're asking openssl to put entropy into PRNGD. > perhaps rather than pseudo random, try a hardware device ? Now, this is a case where you might use openssl rand, in conjunction with engine, to get entropy from another source. That could be a useful hack if you can't easily change PRNGD or the application to read entropy from the device. For example, I think I successfully used openssl with the pkcs11 engine to get entropy from a NitroKey device a couple of years back, when I was playing around with cheap HSMs. Whether something like the NitroKey (which is an inexpensive USB-attached HSM in a thumbdrive form factor) would be useful in this case is something Scott would have to determine. If it is, it'd be cleaner if he could change the application to load the pkcs11 engine and use its RNG directly, or at least get entropy from it to seed OpenSSL's PRNG. > > I know this is caused by a lack of available entropy in the system; but what > > can I do to address this? Is it just a matter of waiting until enough > > entropy > > has been collected? Is there any kind of workaround? Depends on what sources PRNGD uses (I haven't looked), what the device is, what the application is... If the device has sensors you can read, you might be able to gather some entropy by reading noise from them (though this is somewhat fraught - you don't want to overestimate the amount of entropy, and both sensors and sensor APIs are often vulnerable to attack). Sometimes applications ask users to generate some entropy by asking them to bang on the keyboard or wiggle the mouse, or that sort of thing. Again, it really depends on what your device and application are. This topic is discussed at some length in the technical literature; see for example section 3 of RFC 4086. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Unexpected difference between version 10x and 11x
After some RTFM, I found space_ec .. which confirms that this change was intentional. Thanks On 29/05/18 16:27, tincanteksup wrote: Hi, Certificate included here is only for testing. I use EasyRSA to build my PKI -- This all works well. So, now I have a client cert but, depending on which version of openssl I use, I get different output in the Issuer line from the same cert. The difference is: openssl 101f: Issuer: C=00, ST=home, L=tct, O=tct.org, OU=tct.v304.secp384r1.20180529, CN=Easy-RSA CA/emailAddress=m...@example.net openssl 110h Issuer: C = 00, ST = home, L = tct, O = tct.org, OU = tct.v304.secp384r1.20180529, CN = Easy-RSA CA, emailAddress = m...@example.net Note the extra spaces which are inserted around '=' (cat of the original certificate does not show those spaces) My question: Is this change intentional ? I did not feel confident to report this as a bug without asking here first. Thanks for your time and any help/advice you can offer. tct ** Please find full details of output below: $ cat tct.v304.secp384r1.c01.crt Certificate: Data: Version: 3 (0x2) Serial Number: 48:07:85:ec:c8:78:e6:e3:ac:91:54:b3:91:07:83:d5 Signature Algorithm: ecdsa-with-SHA256 Issuer: C=00, ST=home, L=tct, O=tct.org, OU=tct.v304.secp384r1.20180529, CN=Easy-RSA CA/emailAddress=m...@example.net Validity Not Before: May 29 14:01:00 2018 GMT Not After : May 28 14:01:00 2028 GMT Subject: C=00, ST=home, L=tct, O=tct.org, OU=tct.v304.secp384r1.20180529, CN=tct.v304.secp384r1.c01/emailAddress=m...@example.net Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:b2:d4:42:ab:b7:bd:ba:d6:52:b6:9a:ca:30:50: 48:34:5b:72:bf:77:60:c3:7b:4b:fb:18:0f:90:27: a3:bf:f6:db:8b:47:be:04:1f:2a:10:b2:de:7f:6b: f5:e3:5b:12:11:8e:08:85:7c:5b:e8:27:3c:07:fc: 2f:cf:96:50:65:96:60:38:4e:49:ed:d5:b4:23:8e: 7a:64:d8:29:af:e2:c8:4a:49:31:2f:fe:3b:50:99: a1:7d:3b:30:bd:c4:d4 ASN1 OID: secp384r1 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 08:C1:03:47:D4:8E:FD:47:80:6B:33:33:D9:53:97:AF:75:BB:72:20 X509v3 Authority Key Identifier: keyid:3D:05:4B:95:5E:EF:C9:CF:73:00:3B:84:25:F6:65:35:8F:57:A8:F7 DirName:/C=00/ST=home/L=tct/O=tct.org/OU=tct.v304.secp384r1.20180529/CN=Easy-RSA CA/emailAddress=m...@example.net serial:E7:DD:3B:6D:9E:E9:FD:58 X509v3 Extended Key Usage: TLS Web Client Authentication X509v3 Key Usage: Digital Signature Signature Algorithm: ecdsa-with-SHA256 30:64:02:30:4e:39:9a:4b:b0:f9:86:23:00:a1:82:76:8f:ed: e5:3f:20:af:a8:64:f1:b2:10:98:75:ab:64:31:38:a5:bf:a2: ca:be:18:54:12:b5:8c:1d:c9:91:8a:e6:09:c5:16:a3:02:30: 5b:32:d4:7a:d0:2e:97:86:65:51:4f:60:16:51:71:bd:ca:7a: 90:31:5c:0d:62:19:1e:86:29:0c:94:32:1f:33:ce:db:db:b9: 1e:40:0b:55:17:f1:6c:9e:ff:d2:52:03 -BEGIN CERTIFICATE- MIIDljCCAx2gAwIBAgIQSAeF7Mh45uOskVSzkQeD1TAKBggqhkjOPQQDAjCBlzEL MAkGA1UEBhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UE ChMHdGN0Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5 MRQwEgYDVQQDEwtFYXN5LVJTQSBDQTEdMBsGCSqGSIb3DQEJARYObWVAZXhhbXBs ZS5uZXQwHhcNMTgwNTI5MTQwMTAwWhcNMjgwNTI4MTQwMTAwWjCBojELMAkGA1UE BhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UEChMHdGN0 Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5MR8wHQYD VQQDExZ0Y3QudjMwNC5zZWNwMzg0cjEuYzAxMR0wGwYJKoZIhvcNAQkBFg5tZUBl eGFtcGxlLm5ldDB2MBAGByqGSM49AgEGBSuBBAAiA2IABLLUQqu3vbrWUraayjBQ SDRbcr93YMN7S/sYD5Ano7/224tHvgQfKhCy3n9r9eNbEhGOCIV8W+gnPAf8L8+W UGWWYDhOSe3VtCOOemTYKa/iyEpJMS/+O1CZoX07ML3E1KOCAR8wggEbMAkGA1Ud EwQCMAAwHQYDVR0OBBYEFAjBA0fUjv1HgGszM9lTl691u3IgMIHMBgNVHSMEgcQw gcGAFD0FS5Ve78nPcwA7hCX2ZTWPV6j3oYGdpIGaMIGXMQswCQYDVQQGEwIwMDEN MAsGA1UECBMEaG9tZTEMMAoGA1UEBxMDdGN0MRAwDgYDVQQKEwd0Y3Qub3JnMSQw IgYDVQQLExt0Y3QudjMwNC5zZWNwMzg0cjEuMjAxODA1MjkxFDASBgNVBAMTC0Vh c3ktUlNBIENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldIIJAOfdO22e 6f1YMBMGA1UdJQQMMAoGCCsGAQUFBwMCMAsGA1UdDwQEAwIHgDAKBggqhkjOPQQD AgNnADBkAjBOOZpLsPmGIwChgnaP7eU/IK+oZPGyEJh1q2QxOKW/osq+GFQStYwd yZGK5gnFFqMCMFsy1HrQLpeGZVFPYBZRcb3KepAxXA1iGR6GKQyUMh8zztvbuR5A C1UX8Wye/9JSAw== -END CERTIFICATE- ** Now usiing openssl v101f I get $ openssl x509 -in /home/arby/sources/easyrsa/ersa304-1/pki/issued/tct.v304.secp384r1.c01.crt -textCertificate: Data: Version: 3 (0x2) Serial Number: 48:07:85:ec:c8:78:e6:e3:ac:91:54:b3:91:07:83:d5 Signature Algorithm: ecdsa-with-SHA256 Issuer: C=00,
Re: [openssl-users] Test SSL connection
On 30.05.2018 08:45, Mark Shnaider via openssl-users wrote: Hello, I use OpenSSL version is openssl-1.1.0h(Windows) and I run following command from apps directory |openssl s_server -accept 443 -www| The server in this case use certificate "server.pem" On client computer I run command openssl s_client -connect 10.65.48.108:443 On client computer I get error : Verify return code: 21 (unable to verify the first certificate) What is wrong? Thanks for any help Mark very probable, that the client doesn't have the root ca certificate of the ca certificate that signed server.pem you should have at least the following ca.pem - the root ca server.pem - the server ssl/tls certificate Walter smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Test SSL connection
Hello, I use OpenSSL version is openssl-1.1.0h(Windows) and I run following command from apps directory openssl s_server -accept 443 -www The server in this case use certificate "server.pem" On client computer I run command openssl s_client -connect 10.65.48.108:443 On client computer I get error : Verify return code: 21 (unable to verify the first certificate) What is wrong? Thanks for any help Mark -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
