On 12/22/2021 1:33 PM, Philip Prindeville wrote:
> Should supporting openssl.cnf be part of the library API, or
> externally handled in the command-line utility where it then passes in
> the values extracted from that file?
I don't know how openssl.cnf factors into CSR creation with existing
Yeah, self-signed certs are absolutely useful - you just need to be very
careful which ones you trust for what.
Such certs are widely used to provide trust anchor information,
typically of root CAs,
but conceptually and pragmatically, as Jordan also stated below,
they can make much sense even
Yeah, self-signed certs are absolutely useful - you just need to be very
careful which ones you trust for what.
Such certs are widely used to provide trust anchor information,
typically of root CAs,
but conceptually and pragmatically, as Jordan also stated below,
they can make much sense even
> On Dec 22, 2021, at 2:18 PM, Jordan Brown
> wrote:
>
> On 12/22/2021 11:45 AM, David von Oheimb wrote:
>> Yet beware that a general-purpose library function that has (at least) the
>> flexibility offered by that app would need a non-trivial set of parameters.
>>
>
> I suspect that it
On 12/22/2021 11:45 AM, David von Oheimb wrote:
>
> Yet beware that a general-purpose library function that has (at least)
> the flexibility offered by that app would need a non-trivial set of
> parameters.
>
I suspect that it would end up looking a lot like the existing API.
There might be a
On 12/22/2021 1:08 PM, Philip Prindeville wrote:
> I see there being limited application (utility) of self-signed certs, since
> they're pretty much useless from a security perspective, because they're
> unanchored in any root-of-trust.
They're OK once you take a leap of faith, check the
Agree to your very first point about "generate a CSR to be signed elsewhere"
being very different from "generate a self-signed certificate" or even "sign
this CSR" (i.e. become a Registration Authority).
I'm thinking of the case where you have an IoT (a router, a WAP, a digital
camera, a smart
Dear Users,
I have released version 5.61 of stunnel.
### Version 5.61, 2021.12.22, urgency: LOW
* New features sponsored by the University of Maryland
- Added new "protocol = capwin" and "protocol = capwinctrl"
configuration file options.
* New features for the Windows platform
- Added
@Philip,
it should not be hard to copy the core code from apps/req.c and cut out
all parts not needed for generating a PKCS#10 CSR (including its
self-signature).
Yet beware that a general-purpose library function that has (at least)
the flexibility offered by that app would need a
@Philip,
it should not be hard to copy the core code from apps/req.c and cut out
all parts not needed for generating a PKCS#10 CSR (including its
self-signature).
Yet beware that a general-purpose library function that has (at least)
the flexibility offered by that app would need a
>From a conceptual perspective, I think "creating a CSR" should be different
than "signing a CSR with a given keypair", and on that reason alone I'd
separate them, allowing some small code duplication.
The difference between "signing with a certified key" and "signing with its
own key" is really
IMHO, many providers are dynamically loadable modules, i.e. shared objects
(.so). This is in conflict with the "no-shared" flag used.
Petr
From: openssl-users On Behalf Of Lee
Staniforth
Sent: Tuesday, December 21, 2021 4:09 PM
To: openssl-users@openssl.org
Subject: undefined symbol:
I have not compiled OpenSSL 3.0 yet, but I am pretty sure that
-fvisibility=hidden will at least break the temporary shared objects created by
the unit tests, if not everything else in OpenSSL.
Hi
Kernel Support for KTLS:
kernel version is 5.15
CONFIG_TLS=y
CONFIG_TLS_DEVICE=y
CONFIG_CRYPTO_TLS=y
Openssl:
$ ./ Configure enable-ktls linux-aarch64
$ make
Server
$ ./openssl version
OpenSSL 3.0.2-dev 14 Dec 2021 (Library: OpenSSL 3.0.0 7 sep 2021)
$ ./openssl s_server -key rsa.key -cert
14 matches
Mail list logo
