Re: Extension of certificate expiry date
On Mon, Jun 08, 2020 at 07:43:46PM -0700, Anand Sridharan wrote: > We have used hardcoded certificate information in a piece of code , we > don't want to change it often. There aren't any other reasons for it. Just generate a new certificate, you can use the same key if you like. -- Viktor.
Re: Extension of certificate expiry date
Hi Viktor , we have used hardcoded certificate information in a piece of code , we don't want to change it often. There aren't any other reasons for it. On Mon, Jun 8, 2020 at 4:21 PM Viktor Dukhovni wrote: > On Mon, Jun 08, 2020 at 04:01:37PM -0700, Anand Sridharan wrote: > > > is there a way on openssl to extend the expiry of certificate date? > > > > I created a certificate with an expiry date set for 365 days but looking > > now to extend it longer or indefinitely. > > You need to sign a new certificate for the same subject name and public > key. While it is possible to use an existing certificate as a > "template" the new certificate, it is often simpler to just create a new > one. Is there any reason why that's not a good option for you? > > -- > Viktor. > -- thanks, Anand.S
Re: Extension of certificate expiry date
On Mon, Jun 08, 2020 at 04:01:37PM -0700, Anand Sridharan wrote: > is there a way on openssl to extend the expiry of certificate date? > > I created a certificate with an expiry date set for 365 days but looking > now to extend it longer or indefinitely. You need to sign a new certificate for the same subject name and public key. While it is possible to use an existing certificate as a "template" the new certificate, it is often simpler to just create a new one. Is there any reason why that's not a good option for you? -- Viktor.
Extension of certificate expiry date
Hi openssl users, is there a way on openssl to extend the expiry of certificate date? I created a certificate with an expiry date set for 365 days but looking now to extend it longer or indefinitely. -- thanks, Anand.S
Re: Are there any flag that control client finished hash verification
On Mon, Jun 08, 2020 at 06:53:32PM +, Neil Proctor via openssl-users wrote: > Hello, > > Specific to OpenSSL v1.0.2p and TLS1.2 are there any flags or options like, > SSL_CERT_FLAG_TLS_STRICT, that set whether or not the client handshake > finished hash is verified by the server? Or is this always performed > regardless of configuration? > > During some of our testing, it seems that even if the last byte of the client > handshake finished hash gets modified, the server will still accept and > complete the handshake and the TLS connection. Full validation of the Finished is supposed to be done always. Please try to write up some discussion of your test cases; probably a github issue is best (though mail to this list is okay too). Thanks, Ben
Are there any flag that control client finished hash verification
Hello, Specific to OpenSSL v1.0.2p and TLS1.2 are there any flags or options like, SSL_CERT_FLAG_TLS_STRICT, that set whether or not the client handshake finished hash is verified by the server? Or is this always performed regardless of configuration? During some of our testing, it seems that even if the last byte of the client handshake finished hash gets modified, the server will still accept and complete the handshake and the TLS connection. Thanks
Re: How to help with getting KTLS patches merged
On Thu, Jun 04, 2020 at 09:00:08AM -0700, John Baldwin wrote: > At the moment there are 3 open PRs related to Kernel TLS offload > support that I'm aware of: > > - 11589 adds TLS1.3 for Linux, has one approval from Matt Caswell > - 10626 adds TLS1.3 for FreeBSD, from which 11589 is derived, but will > need to be rebased on top of 11589 once it is merged > - 11679 adds TLS1.[012] RX offload for FreeBSD, but would conflict > a bit with 11589 > > Matt has already approved 11589, and I think 11589 looks ok from > my vantage point (I'm more familiar with the KTLS infrastructure > in FreeBSD rather than Linux). Given that 11589 has received the > most review, I think it is probably prudent for it to be merged > first at for me to then rebase the other two PRs on top of that > and resolve conflicts, etc. 11589 has now been merged. Kurt
