Re: [openssl-users] OpenSSL in Linux kernel

[Matěj Cepl]

On 2016-04-21, 20:50 GMT, Lei Kong wrote:
> Can SSL library be used in Linux kernel mode?

A bit of problem is that the OpenSSL’s license is incompatible 
with GPLv2.

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
How many Bavarian Illuminati does it take to screw in a light
bulb?
Three: one to screw it in, and one to confuse the issue.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL in Linux kernel

[Viktor Dukhovni]

On Thu, Apr 21, 2016 at 09:00:07PM +, Salz, Rich wrote:
> 
> > Can SSL library be used in Linux kernel mode?
> 
> The crypto libraries can, and are in some places, in the kernel.
> 
> If you want to put the SSL/TLS protocol into the kernel, you will need to do 
> some work, just as writing a BIO type that works in the kernel and perhaps 
> malloc/free routines, probably some other stuff.
> 
> That would be cool to see :)    

It might not be so simple.  The kernel is preemptable and must not
block.  libssl is not designed with the kernel in mind.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL in Linux kernel

[Salz, Rich]

> Can SSL library be used in Linux kernel mode?

The crypto libraries can, and are in some places, in the kernel.

If you want to put the SSL/TLS protocol into the kernel, you will need to do 
some work, just as writing a BIO type that works in the kernel and perhaps 
malloc/free routines, probably some other stuff.

That would be cool to see :)    
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL in Linux kernel

[Lei Kong]

Can SSL library be used in Linux kernel mode?
Thanks.

  -- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Problem with OSCP Server Response

[Juan Sebastián Cárdenas Arenas]

Good Morning

My name is Juan Sebastian Cardenas, I'm a Systems engineer from Colombia

I am implementing an internal PKI for the organization where I work using 
openssl

The idea is to generate certificates and digital signatures to members of the 
organization so that they can sign documents of the office suite and eliminate 
the use of paper

I have success in creating the keys and certificates from a ca root and an 
intermediary, I am using the intermediary to sign certificates of users and the 
server OCSP

When creating user certificates I am defining the URI of OCSP server so that it 
can verify the validity of the certificate

And finally I am exporting user certificates to a pkcs12 format (.p12) to 
install the certificate and key user on the user's computer

After installing the pkcs12 key on user's computer, I can use the programs of 
the office suite (word, excel, power point, etc..) to sign documents using the 
installed digital signature, however, only makes the connection to the OCSP 
server once and then no longer allow any verification or validation.

In reviewing the response from the OCSP server:
Invalid request
Reply Error: malformedRequest (1)

And then in the Office program, I can´t use the digital signature to sign 
documents anymore, and present the message the selected certificate can not be 
verified. Check the network connection (as had already been able to connect the 
first time)

Ask them please guide me regarding this specific error check with the OCSP 
server response.

Thanks for all your help


Juan Sebastian Cardenas Arenas

Docente TC - Dirección de Investigaciones
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] missing symbolic links under include directory

[Thomas Francis, Jr.]

> On Apr 21, 2016, at 3:06 AM, Tim Culhane  wrote:
> 
> Hi all,
> 
> My company makes calls to functions in the openssl source and thus includes
> header files defined in the openssl library.
> 
> Typically these header files were gathered together in a simgle place, under
> include/openssl by way of symbolic links to the real header file locations.
> 
> At present I'm updating the version of openssl our products used from 1.0.1g
> to 1.0.2g, the latest stable release.
> 
> I noticed that when I unpacked the source code for openssl 1.0.2g that there
> were no symbolic links under the include/openssl directory.
> 
> These were present in versions of openssl as late as 1.0.1q.
> From looking through the mailing list archive, I believe this was a
> deliberate change in how openssl is packaged. Is this correct?
> 
> It appears that the configure or config script now needs to be run followed
> by make depend in order to regenerate the symbolic links.

You must run the configure script (and possibly make depend) to get the links 
created properly.  My understanding is the deliberate change was more in the 
way of correcting archives that were made incorrectly; you’ve always (at least 
as long as I’ve been using OpenSSL, which has been almost 20 years) had to do 
this.

It’s worth noting that configuring openssl will remove all of those links 
before creating them again, too, so as far as the symlinks go, having them 
around isn’t too bad, it’s just extra work.

> My issue is that our products check out the openssl source from a local git
> repository and the products build on both linux and sparc.
> 
> Therefore, if I commit the latest openssl source code to our git repository
> it must already contain the symbolic links required.

Why?  You should not keep installed headers in source control — you should use 
a binary repository (and keep the binaries and headers together) instead.  OR, 
see below...

> If I run config or configure followed by make depend before committing the
> source code to git, will I be generating any operating specific files or
> code?

Yes.  What’s worse is that if you commit all the files, when you try to 
configure OpenSSL on the second platform, it’ll tell you that it’s already been 
configured for the first platform and stop.

> In other words, if I do config on sparc followed by make depend and then
> commit the source to git, would there be any issues when I later checked out
> the
> files from git and built them on linux?

Again, yes, there will be problems.  If you want to build OpenSSL out of your 
source control on a regular basis, you should store the source files exactly as 
they exist in the tarball.  Remove those headers from your source control — you 
don’t need them in order to build; they’re just wasting space in your source 
control. :)

This means that each time you pull the code from source control, you configure 
and build the code as normal (which I assume you’re already doing — if not, 
OpenSSL probably isn’t working as it’s supposed to be working).

If you don’t want to build OpenSSL all the time (and unless you maintain your 
own patches, I strongly recommend against building it all the time), then don’t 
keep it under source control at all.  Keep it in some kind of binary repository 
which you update only when you need to upgrade OpenSSL (or add a patch, a new 
platform, etc).  Then use that for deploying OpenSSL to your build systems as 
needed (presumably only once per build system).  If you use some kind of system 
imaging to spin up new VMs for building, then make sure the OpenSSL 
installation is part of that system, so it gets installed with the new VM, not 
as part of your build process.  That has the additional benefit of reducing 
your build times. :)  If you need to have multiple versions of OpenSSL 
installed, simply configure each version to be installed to a different 
location (and install them to different locations), and adjust your other 
builds to look for the version they want in the version-specific location.  
That has the additional benefit of making it clear to everyone what version of 
OpenSSL is used by what build.

TOM


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] missing symbolic links under include directory

[Tim Culhane]

Hi all,

My company makes calls to functions in the openssl source and thus includes
header files defined in the openssl library.

Typically these header files were gathered together in a simgle place, under
include/openssl by way of symbolic links to the real header file locations.

At present I'm updating the version of openssl our products used from 1.0.1g
to 1.0.2g, the latest stable release.

I noticed that when I unpacked the source code for openssl 1.0.2g that there
were no symbolic links under the include/openssl directory.

These were present in versions of openssl as late as 1.0.1q.

>From looking through the mailing list archive, I believe this was a
deliberate change in how openssl is packaged. Is this correct?

It appears that the configure or config script now needs to be run followed
by make depend in order to regenerate the symbolic links.

My issue is that our products check out the openssl source from a local git
repository and the products build on both linux and sparc.

Therefore, if I commit the latest openssl source code to our git repository
it must already contain the symbolic links required.

If I run config or configure followed by make depend before committing the
source code to git, will I be generating any operating specific files or
code?

In other words, if I do config on sparc followed by make depend and then
commit the source to git, would there be any issues when I later checked out
the
files from git and built them on linux?

Many thanks for any clarification you can provide.

Tim

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users