[openssl-users] Wrapper script for creating PKI with openssl Was: OpenSSL version 1.1.1 pre release 9 published
Changing Subject to help googlability :) On Monday, 27 August 2018 22:38:24 CEST Robert Moskowitz wrote: > On 08/27/2018 04:07 PM, Hubert Kario wrote: > > now, for generating testing certificates (and what's more important, the > > whole PKI) we are using this script to provide sensible defaults and easy > > way to generate certificates with just few options departing from those > > defaults: https://github.com/redhat-qe-security/certgen > > I will take a look at this. It did not come up in my google searches a > year ago. Guess just not asking the right question or github is > protected from google... definitely isn't; most of the visits on my other repos come from google (if github stats are to be believed) likely because similar scripts are not uncommon (e.g. OpenVPN ships with something similar) and this one is hardly well known, so it got delegated to "2nd page" > > to get a PKI you run those commands: > > source certgen/lib.sh > > x509KeyGen ca > > x509KeyGen server > > x509SelfSign ca > > x509CertSign --CA ca server > > > > The private key file will be printed by use of: > > x509Key server > > to get certificate file name you run: > > x509Cert server > > In testing situations I have been in, intermediate CAs, revocation, the > like are needed. it allows you to create arbitrarily complex CA structure, this is just the simplest example; there is also support for generating client certificates, OCSP reponder certificates, subject alternative names, etc. to get an intermediate you have to run the following commands: x509KeyGen subca x509CertSign --CA ca -t CA subca" the you can use 'subca' instead of 'ca' for signing the server cert: x509CertSign --CA subca server (the -t of 'webserver' is simply the default) revocation is not implemented yet, but as the tool keeps all the information about CA's signed certificates (it does use internally the `openssl ca` tool), adding it shouldn't be too hard... (and you can always do it manually) > Plus getting more interest in 802.1AR certs with vendors (can't get > certs to test out my product design). that I'm not familiar with > > (easy switches are also provided to get DER files or PKCS#12 files instead > > of the default PEM format) > > I will be interested to see how you handle DER, as I found cases where > the command line was broken. Read my caveat section. In some cases you > have to make the file in PEM then convert to DER. Plus there is no DER > way to handle cert chains as was discussed here a year ago. So I will > be interested to see how you handle cert chains non-PEM. The scripts internally keep everything as PEM files; DER, PKCS#12, etc. are for export only. If you want cert chains you have to create them manually. As I started to work on this script for the CA cross-signing, the built-in assumption was that there is no One True Cert Chain™. So it considers all CAs as stand-alone. If you want a cert chain you have to assemble it yourself. > > to get ecdsa certificate, you just need to change one of the above lines > > with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS certificate? do > > `-t rsa-pss`. > > > > See runtest.sh for other examples. > > I will take a look. Limited time offer! Call now and get Ed25519 support completely free! ;) https://github.com/redhat-qe-security/certgen/commit/ 4b71e0a7d77929d944cc20f16f2ccf9514d6d94d > > It is compatible with all versions of openssl since RHEL-4 (so 0.9.7), if > > a > > given feature is supported in that version of openssl. > > > > (while ed25519 support is not yet there, it will be in few weeks, I was > > running just basic tests of it, without involving full PKI) > > Nice. See https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki > > I am right now adding an algorithm variable to support ed488. > > This actually does not work right with 1.1.1-pre9, as PR 6901 did not > make that build, so I have to do my command and .cnf patches still. yes, there are quite a few warts you need to worry about when working with different versions of OpenSSL, then there is the problem of updating it as recommended key sizes or hashes change... reading that draft feels like reading a heavily commented script – not a criticism, rather observation about the problem at hand -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL version 1.1.1 pre release 9 published
On 08/27/2018 04:55 PM, Benjamin Kaduk via openssl-users wrote: On Mon, Aug 27, 2018 at 04:38:24PM -0400, Robert Moskowitz wrote: On 08/27/2018 04:07 PM, Hubert Kario wrote: On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote: On 08/27/2018 02:33 PM, Hubert Kario wrote: On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: Over the years and in protocol design development, I have heard too many we can't. So I set about with, "here is one way." Since then I have had a few people actually thank me for making it possible for them to build an ecdsa pki for their product testing needs. Just one justifies my effort. well, I see nothing wrong with providing documentation and how-to's, I just don't see that it should be elevated to an Internet Draft level... Well, see https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/ . Warren is a riot. I really should have put in a typo comment to him about 'safely razor' which probably should be 'safety razor'. But then kind of knowing Warren, this could have been intentional so I left it alone. :) by its very nature it needs to be constantly updated, so having it in a static RFC is contrary to that that is the value of Internet Drafts that many of us IETFers have figured out. draft versions can just keep on going and the tools will take you to the current draft. IDs have become neat working documents, though there is more github work coming along. More workgroups are doing requirements docs that will never be published as RFCs; they will stay as IDs. Much better source of why did the wg do? than plow through the old mailing list archives. The IESG is actually encouraging such a use of IDs. Yup! Internet-Draft is a fine terminus for some types of document. Many TLS registries now have a registration policy that explicitly calls out an internet-draft that is never published as anything else, as a valid specification for getting a codepoint assignment. -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL version 1.1.1 pre release 9 published
On Mon, Aug 27, 2018 at 04:38:24PM -0400, Robert Moskowitz wrote: > > > On 08/27/2018 04:07 PM, Hubert Kario wrote: > >On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote: > >>On 08/27/2018 02:33 PM, Hubert Kario wrote: > >>>On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: > >> > >>Over the years and in protocol design development, I have heard too many > >>we can't. So I set about with, "here is one way." Since then I have > >>had a few people actually thank me for making it possible for them to > >>build an ecdsa pki for their product testing needs. Just one justifies > >>my effort. > >well, I see nothing wrong with providing documentation and how-to's, I just > >don't see that it should be elevated to an Internet Draft level... Well, see https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/ . > >by its very nature it needs to be constantly updated, so having it in a > >static > >RFC is contrary to that > > that is the value of Internet Drafts that many of us IETFers have figured > out. draft versions can just keep on going and the tools will take you to > the current draft. IDs have become neat working documents, though there is > more github work coming along. More workgroups are doing requirements docs > that will never be published as RFCs; they will stay as IDs. Much better > source of why did the wg do? than plow through the old mailing list > archives. The IESG is actually encouraging such a use of IDs. Yup! Internet-Draft is a fine terminus for some types of document. Many TLS registries now have a registration policy that explicitly calls out an internet-draft that is never published as anything else, as a valid specification for getting a codepoint assignment. -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL version 1.1.1 pre release 9 published
On 08/27/2018 04:07 PM, Hubert Kario wrote: On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote: On 08/27/2018 02:33 PM, Hubert Kario wrote: On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: On 08/23/2018 09:00 AM, Tomas Mraz wrote: On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: On 08/22/2018 11:48 AM, Matt Caswell wrote: On 22/08/18 00:53, Robert Moskowitz wrote: On 08/21/2018 06:31 PM, Matt Caswell wrote: On 21/08/18 16:24, Robert Moskowitz wrote: Thanks! Once Fedora beta picks this up, I will run my scripts against it and see if all cases of hash with ED25519 are fixed. Unfortunately the command line usability changes for this didn't make it into the beta. They should still be in the final release. Sigh. That means you will get it right. Right? :) Change seems simple enough. The relevant change has now been merged to master. Fedora had already built pre9.1. But on the off chance, I will look at it with tomorrow's build. I'm sorry but no, I am not updating Fedora with current git tree checkout. You'll have to wait for the next prerelease or the final version if there are no further prereleases. Tomas, Thanks for responding here. I have been preparing an Internet Draft on how to build an ED25519 pki. I know have the choice of: building my own 1.1.1 pre9 for testing. Wait to push the draft out until 1.1.1 is fully released. Fudge the draft by adding yet another caveat (yes there is a caveat section that I developed in creating the ECDSA pki draft) that the commands are for how it is suppose to work in production 1.1.1, not what I had to do in the prerelease. Decisions decisions. Thing is I want the draft out so I can push for EDDSA support in IEEE 802.1AR with the next meeting early Sept. I'm not sure if providing command line examples for one particular tool are a good idea... Example certificates, sure, but not commands to generate them... "We can't test out the security part of the protocol because we cannot get certificates" "We ran our tests with security disable because we could not afford the cost and time for a test pki." "We did test with RSA certificates from vendor A." (and they were using old libs that would not support ecdsa, but marketed it as such.)" Over the years and in protocol design development, I have heard too many we can't. So I set about with, "here is one way." Since then I have had a few people actually thank me for making it possible for them to build an ecdsa pki for their product testing needs. Just one justifies my effort. well, I see nothing wrong with providing documentation and how-to's, I just don't see that it should be elevated to an Internet Draft level... by its very nature it needs to be constantly updated, so having it in a static RFC is contrary to that that is the value of Internet Drafts that many of us IETFers have figured out. draft versions can just keep on going and the tools will take you to the current draft. IDs have become neat working documents, though there is more github work coming along. More workgroups are doing requirements docs that will never be published as RFCs; they will stay as IDs. Much better source of why did the wg do? than plow through the old mailing list archives. The IESG is actually encouraging such a use of IDs. now, for generating testing certificates (and what's more important, the whole PKI) we are using this script to provide sensible defaults and easy way to generate certificates with just few options departing from those defaults: https://github.com/redhat-qe-security/certgen I will take a look at this. It did not come up in my google searches a year ago. Guess just not asking the right question or github is protected from google... to get a PKI you run those commands: source certgen/lib.sh x509KeyGen ca x509KeyGen server x509SelfSign ca x509CertSign --CA ca server The private key file will be printed by use of: x509Key server to get certificate file name you run: x509Cert server In testing situations I have been in, intermediate CAs, revocation, the like are needed. Plus getting more interest in 802.1AR certs with vendors (can't get certs to test out my product design). (easy switches are also provided to get DER files or PKCS#12 files instead of the default PEM format) I will be interested to see how you handle DER, as I found cases where the command line was broken. Read my caveat section. In some cases you have to make the file in PEM then convert to DER. Plus there is no DER way to handle cert chains as was discussed here a year ago. So I will be interested to see how you handle cert chains non-PEM. to get ecdsa certificate, you just need to change one of the above lines with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS certificate? do `-t rsa-pss`. See runtest.sh for other examples. I will take a look. It is compatible with all versions of openssl since RHEL-4 (so 0.9.7), if a given
Re: [openssl-users] OpenSSL version 1.1.1 pre release 9 published
On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote: > On 08/27/2018 02:33 PM, Hubert Kario wrote: > > On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: > >> On 08/23/2018 09:00 AM, Tomas Mraz wrote: > >>> On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: > On 08/22/2018 11:48 AM, Matt Caswell wrote: > > On 22/08/18 00:53, Robert Moskowitz wrote: > >> On 08/21/2018 06:31 PM, Matt Caswell wrote: > >>> On 21/08/18 16:24, Robert Moskowitz wrote: > Thanks! > > Once Fedora beta picks this up, I will run my scripts against > it and see > if all cases of hash with ED25519 are fixed. > >>> > >>> Unfortunately the command line usability changes for this > >>> didn't make it > >>> into the beta. They should still be in the final release. > >> > >> Sigh. That means you will get it right. Right? :) > >> > >> Change seems simple enough. > > > > The relevant change has now been merged to master. > > Fedora had already built pre9.1. But on the off chance, I will look > at > it with tomorrow's build. > >>> > >>> I'm sorry but no, I am not updating Fedora with current git tree > >>> checkout. You'll have to wait for the next prerelease or the final > >>> version if there are no further prereleases. > >> > >> Tomas, > >> > >> Thanks for responding here. > >> > >> I have been preparing an Internet Draft on how to build an ED25519 pki. > >> I know have the choice of: > >> > >> building my own 1.1.1 pre9 for testing. > >> Wait to push the draft out until 1.1.1 is fully released. > >> Fudge the draft by adding yet another caveat (yes there is a caveat > >> section that I developed in creating the ECDSA pki draft) that the > >> commands are for how it is suppose to work in production 1.1.1, not what > >> I had to do in the prerelease. > >> > >> Decisions decisions. Thing is I want the draft out so I can push for > >> EDDSA support in IEEE 802.1AR with the next meeting early Sept. > > > > I'm not sure if providing command line examples for one particular tool > > are a good idea... > > > > Example certificates, sure, but not commands to generate them... > > "We can't test out the security part of the protocol because we cannot > get certificates" > "We ran our tests with security disable because we could not afford the > cost and time for a test pki." > "We did test with RSA certificates from vendor A." (and they were using > old libs that would not support ecdsa, but marketed it as such.)" > > Over the years and in protocol design development, I have heard too many > we can't. So I set about with, "here is one way." Since then I have > had a few people actually thank me for making it possible for them to > build an ecdsa pki for their product testing needs. Just one justifies > my effort. well, I see nothing wrong with providing documentation and how-to's, I just don't see that it should be elevated to an Internet Draft level... by its very nature it needs to be constantly updated, so having it in a static RFC is contrary to that now, for generating testing certificates (and what's more important, the whole PKI) we are using this script to provide sensible defaults and easy way to generate certificates with just few options departing from those defaults: https://github.com/redhat-qe-security/certgen to get a PKI you run those commands: source certgen/lib.sh x509KeyGen ca x509KeyGen server x509SelfSign ca x509CertSign --CA ca server The private key file will be printed by use of: x509Key server to get certificate file name you run: x509Cert server (easy switches are also provided to get DER files or PKCS#12 files instead of the default PEM format) to get ecdsa certificate, you just need to change one of the above lines with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS certificate? do `-t rsa-pss`. See runtest.sh for other examples. It is compatible with all versions of openssl since RHEL-4 (so 0.9.7), if a given feature is supported in that version of openssl. (while ed25519 support is not yet there, it will be in few weeks, I was running just basic tests of it, without involving full PKI) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL version 1.1.1 pre release 9 published
On 08/27/2018 02:33 PM, Hubert Kario wrote: On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: On 08/23/2018 09:00 AM, Tomas Mraz wrote: On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: On 08/22/2018 11:48 AM, Matt Caswell wrote: On 22/08/18 00:53, Robert Moskowitz wrote: On 08/21/2018 06:31 PM, Matt Caswell wrote: On 21/08/18 16:24, Robert Moskowitz wrote: Thanks! Once Fedora beta picks this up, I will run my scripts against it and see if all cases of hash with ED25519 are fixed. Unfortunately the command line usability changes for this didn't make it into the beta. They should still be in the final release. Sigh. That means you will get it right. Right? :) Change seems simple enough. The relevant change has now been merged to master. Fedora had already built pre9.1. But on the off chance, I will look at it with tomorrow's build. I'm sorry but no, I am not updating Fedora with current git tree checkout. You'll have to wait for the next prerelease or the final version if there are no further prereleases. Tomas, Thanks for responding here. I have been preparing an Internet Draft on how to build an ED25519 pki. I know have the choice of: building my own 1.1.1 pre9 for testing. Wait to push the draft out until 1.1.1 is fully released. Fudge the draft by adding yet another caveat (yes there is a caveat section that I developed in creating the ECDSA pki draft) that the commands are for how it is suppose to work in production 1.1.1, not what I had to do in the prerelease. Decisions decisions. Thing is I want the draft out so I can push for EDDSA support in IEEE 802.1AR with the next meeting early Sept. I'm not sure if providing command line examples for one particular tool are a good idea... Example certificates, sure, but not commands to generate them... "We can't test out the security part of the protocol because we cannot get certificates" "We ran our tests with security disable because we could not afford the cost and time for a test pki." "We did test with RSA certificates from vendor A." (and they were using old libs that would not support ecdsa, but marketed it as such.)" Over the years and in protocol design development, I have heard too many we can't. So I set about with, "here is one way." Since then I have had a few people actually thank me for making it possible for them to build an ecdsa pki for their product testing needs. Just one justifies my effort. If my making EDDSA certs easy for testing and I get one IoT product using certs that would otherwise claim that their product could not support the overhead of certs, it has been worth it. I don't expect RFCs from these draft. Now Internet Drafts live forever (the drafts Yakov and I did for RFC 1597 are gone). So my work will be around for others to use without a lot of pecking at google and this list to get it working. And with eddsa, I did find one issue. I was on the front side of things for a change. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL version 1.1.1 pre release 9 published
Since this example would show how to generate certificates that people may not have a lot of experience dealing with - I think it would make a lot of sense to document as much as possible. In short: yes please do include the examples of both what the certs should look like, and how to generate them. On 8/27/18, 2:34 PM, "openssl-users on behalf of Hubert Kario" wrote: On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: > On 08/23/2018 09:00 AM, Tomas Mraz wrote: > > On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: > >> On 08/22/2018 11:48 AM, Matt Caswell wrote: > >>> On 22/08/18 00:53, Robert Moskowitz wrote: > On 08/21/2018 06:31 PM, Matt Caswell wrote: > > On 21/08/18 16:24, Robert Moskowitz wrote: > >> Thanks! > >> > >> Once Fedora beta picks this up, I will run my scripts against > >> it and see > >> if all cases of hash with ED25519 are fixed. > > > > Unfortunately the command line usability changes for this > > didn't make it > > into the beta. They should still be in the final release. > > Sigh. That means you will get it right. Right? :) > > Change seems simple enough. > >>> > >>> The relevant change has now been merged to master. > >> > >> Fedora had already built pre9.1. But on the off chance, I will look > >> at > >> it with tomorrow's build. > > > > I'm sorry but no, I am not updating Fedora with current git tree > > checkout. You'll have to wait for the next prerelease or the final > > version if there are no further prereleases. > > Tomas, > > Thanks for responding here. > > I have been preparing an Internet Draft on how to build an ED25519 pki. > I know have the choice of: > > building my own 1.1.1 pre9 for testing. > Wait to push the draft out until 1.1.1 is fully released. > Fudge the draft by adding yet another caveat (yes there is a caveat > section that I developed in creating the ECDSA pki draft) that the > commands are for how it is suppose to work in production 1.1.1, not what > I had to do in the prerelease. > > Decisions decisions. Thing is I want the draft out so I can push for > EDDSA support in IEEE 802.1AR with the next meeting early Sept. I'm not sure if providing command line examples for one particular tool are a good idea... Example certificates, sure, but not commands to generate them... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL version 1.1.1 pre release 9 published
On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: > On 08/23/2018 09:00 AM, Tomas Mraz wrote: > > On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: > >> On 08/22/2018 11:48 AM, Matt Caswell wrote: > >>> On 22/08/18 00:53, Robert Moskowitz wrote: > On 08/21/2018 06:31 PM, Matt Caswell wrote: > > On 21/08/18 16:24, Robert Moskowitz wrote: > >> Thanks! > >> > >> Once Fedora beta picks this up, I will run my scripts against > >> it and see > >> if all cases of hash with ED25519 are fixed. > > > > Unfortunately the command line usability changes for this > > didn't make it > > into the beta. They should still be in the final release. > > Sigh. That means you will get it right. Right? :) > > Change seems simple enough. > >>> > >>> The relevant change has now been merged to master. > >> > >> Fedora had already built pre9.1. But on the off chance, I will look > >> at > >> it with tomorrow's build. > > > > I'm sorry but no, I am not updating Fedora with current git tree > > checkout. You'll have to wait for the next prerelease or the final > > version if there are no further prereleases. > > Tomas, > > Thanks for responding here. > > I have been preparing an Internet Draft on how to build an ED25519 pki. > I know have the choice of: > > building my own 1.1.1 pre9 for testing. > Wait to push the draft out until 1.1.1 is fully released. > Fudge the draft by adding yet another caveat (yes there is a caveat > section that I developed in creating the ECDSA pki draft) that the > commands are for how it is suppose to work in production 1.1.1, not what > I had to do in the prerelease. > > Decisions decisions. Thing is I want the draft out so I can push for > EDDSA support in IEEE 802.1AR with the next meeting early Sept. I'm not sure if providing command line examples for one particular tool are a good idea... Example certificates, sure, but not commands to generate them... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- 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?
On Saturday, 18 August 2018 19:48:21 CEST Juan Isoza wrote: > What is the difference between draft 28 and rfc for tls 1.3 ? the downgrade protection mechanism gets enabled for the first time -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 release
On 27/08/18 13:50, Juan Isoza wrote: > Openssl 1.1.1 pre 9 is now compatible with final RFC tls 1.3 > > but I see several recent commit , so I suppose we'll see a pre 10 before > final openssl 1.1.1 > > > Any idea for the possible date of publication of 1.1.1 final (if there > is no major bug/problem) ? We are hoping that pre 9 will be the last beta and the next release will be the final one. We have tentatively discussed 11th September as a possible release date - but no definitive decisions on this yet. Matt > > regards > juan > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl 1.1.1 release
Openssl 1.1.1 pre 9 is now compatible with final RFC tls 1.3 but I see several recent commit , so I suppose we'll see a pre 10 before final openssl 1.1.1 Any idea for the possible date of publication of 1.1.1 final (if there is no major bug/problem) ? regards juan -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
