Problems with compiling and linking fips_premain.c and fingerprint mismatch

[Sairam Rangaswamy -X (sairanga - Aricent Technologies at Cisco)]

Hi,

We are working on porting FIPS compliant Openssl to a vxworks (5.4) based 
platform, running on MPC85xx cpu family.
I compiled the FOM (version 3.0) which includes the complete fips modules 
(fipscanister.ofips_premain.o). This is a statically
linked library. So, the libcrypto.a and libss.a files that are generated by 
building the FIPS and openssl modules
are linked to a final elf format binary file. Apart from this application 
binary, there is a kernel binary and driver binary
that are downloaded to the target.

I am using the fipsld script to do the final linking and build. But the vxworks 
version we use does not support
the __attribute__ and constructor etc defined in fips_premain.c. So, I copied 
all the code from fips_premain.c
to fips.c and compiled the FOM (3.0) and SSL modules to create libcrypto.a and 
libssl.o. I know this will
create fingerprint mismatch for the fips.c and the final libcrypto.a as well.

I tried to invoke the fipsld. But it gave linker errors and -o related errors. 
So, I invoked the incore script directly
which generates and embeds the signature into the FINGERPRINT_ascii_value of 
the cross-compiled libcrypto.a.
The incore script properly copies the signature into the object.

Then, this object is sent through the gzip processing and loaded into the 
target.

In the target, I am calling the FINGERPRINT_premain() manually first. It copies 
the converted FINGERPRINT_ascii_value
into the FIPS_signature. But after that FIPS_mode_set(1) is failing with finger 
print mismatch. Selftest fails too
because of the same reason.

Any idea how I can resolve these issues?

I am suspecting the object might be relocated during loading in target. That 
could be the reason for fingerprint
mismatch on the target?
Or is there  a difference between the SHA1 key calculation algorithm in incore 
file and the target FIPS_incore_fingerprint
calculation? I could not find any visible difference. The incore script is a 
perl script which implements the same
HMAC package that is running in the target. I am attaching the incore script 
file as wel.

Thanks,
R. Sairam



incore
Description: incore

Re: SSL_VERIFY_PEER and self-signed certificates

[Brice André]

Hello Dave,

Thank you for your answer.

You are right, I am using a self-signed certificate for use by my
server. In fact, I do not perform client authentication in my
application : only the server shall be authentified by ssl. The client
is authentified by another mechanism.

Here are how I generate my RSA key and my certificate:

openssl genrsa -des -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 2 -in server.csr -signkey server.key -out server.crt

The only file that I transmit to my client is server.crt.

I think that all those files are OK because, on the server side, once
everything is initialised, the command SSL_CTX_check_private_key is
happy with it.

In order to initialise the truststore of my client, I copy the
server.crt file somewhere, and I execute the following command :

SSL_CTX_use_certificate_file(ctx,path_to_file, SSL_FILETYPE_PEM);

Do I have to generate another file ? Or do I have to perform another
configuration in my client ?

Regards,
Brice


2013/5/28 Dave Thompson :
>> From: owner-openssl-us...@openssl.org On Behalf Of Brice André
>> Sent: Monday, 27 May, 2013 14:48
>
>> I am writing a client-server application  I plan to
>> generate my self-signed certificate and to embed it in my client.
>>
> To be clear, a self-signed cert for (used by) the server.
> A self-signed cert for the client would be different, but
> client-auth is rarely used and I expect you would have said so.
>
>> Now, my problem is that, when I configure openssl to check the peer
>> certificate, with the SSL_set_verify command and the SSL_VERIFY_PEER
>> option, I get the error X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT when
>> handshaking the connection on the client side.
>>
>> My understanding of this error is that, by default, open-ssl is not
>> accepting self-signed certificates.
>>
> Are you setting up the client truststore, and how? By default
> openssl doesn't trust *any* peer cert, self-signed or not.
> If you are setting up truststore, you aren't doing it right.
>
>> So, my question is how can I configure open-ssl to accept self-signed
>> certificates ?
>>
> Put a self-signed entity cert, like a CA root (also self-signed),
> in the (client's) truststore using _default_verify_paths,
> _load_verify_locations, or "by hand", as applicable.
>
> One gotcha specific to self-signed EE certs at least in openssl:
> if the KeyUsage extension is present it must include CertSign (in
> addition to digSign and maybe keyEnc needed in a CA-issued EE cert).
>
>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: server certificate verification fails

[Dave Thompson]

>From: owner-openssl-us...@openssl.org On Behalf Of Hazrat Shah
>Sent: Friday, 24 May, 2013 19:48

>I add the server certificate in PEM format to the SSL store using []
>X509_STORE_add_cert(SSL_CTX_get_cert_store(pctx), x509cert);

I assume you mean to the truststore of the (or a) client, since 
that's the only party that normallyh will validate it.

The argument to _add_cert is internal format (X509* = struct x509_st*).
You may have converted it *from* PEM, or DER, or even something else.

>The SSL_get_verify_result(SSL handle); always seems to return
>error code 20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY.

You only get verify 20 if the server cert is NOT selfsigned.
If the server cert is not selfsigned, putting it in the client 
truststore is completely useless. If the server cert is issued 
by a CA (not selfsigned) then an openssl client's trustore must 
include the root cert of that CA (which is selfsigned) but 
need not and should not include the server EE cert.

In addition, if the server cert requires any intermediate "chain" 
certs between it and the CA's root, the server should send them. 
But if due to server misconfiguration or limitation it does not, 
openssl client can fill them in iff they are in the truststore, 
and link uniquely.

The server should have the CA root and any intermediate(s), but 
if it doesn't or you can't get them, or you just prefer to, you 
can normally get them directly from the CA. Commandline s_client 
lists the known part of the chain even though it doesn't validate, 
which should give you a hint where to look. Otherwise take the 
received cert (and intermediate(s) with -showcerts) and run (each) 
through commandline x509 -noout -text to see Policy CRLDP AIA.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: SSL_VERIFY_PEER and self-signed certificates

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of Brice André
> Sent: Monday, 27 May, 2013 14:48

> I am writing a client-server application  I plan to
> generate my self-signed certificate and to embed it in my client.
> 
To be clear, a self-signed cert for (used by) the server.
A self-signed cert for the client would be different, but 
client-auth is rarely used and I expect you would have said so.

> Now, my problem is that, when I configure openssl to check the peer
> certificate, with the SSL_set_verify command and the SSL_VERIFY_PEER
> option, I get the error X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT when
> handshaking the connection on the client side.
> 
> My understanding of this error is that, by default, open-ssl is not
> accepting self-signed certificates.
> 
Are you setting up the client truststore, and how? By default 
openssl doesn't trust *any* peer cert, self-signed or not.
If you are setting up truststore, you aren't doing it right.

> So, my question is how can I configure open-ssl to accept self-signed
> certificates ?
> 
Put a self-signed entity cert, like a CA root (also self-signed),
in the (client's) truststore using _default_verify_paths, 
_load_verify_locations, or "by hand", as applicable. 

One gotcha specific to self-signed EE certs at least in openssl:
if the KeyUsage extension is present it must include CertSign (in 
addition to digSign and maybe keyEnc needed in a CA-issued EE cert).


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

SSL_VERIFY_PEER and self-signed certificates

[Brice André]

Hello everyone,

I am writing a client-server application in C++ with open-ssl to
secure the connection.

At this stage I successfully implemented all communication between my
server and client with ssl encryption, but I am still missing a
feature : checking the certificate of my server.

As I am using this for securing a connection between my server and my
client application installed on different machines, I do not plan to
get a certificate from verisign or another ssl authority : I plan to
generate my self-signed certificate and to embed it in my client.

Now, my problem is that, when I configure openssl to check the peer
certificate, with the SSL_set_verify command and the SSL_VERIFY_PEER
option, I get the error X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT when
handshaking the connection on the client side.

My understanding of this error is that, by default, open-ssl is not
accepting self-signed certificates.

So, my question is how can I configure open-ssl to accept self-signed
certificates ?

Thanks in advance,
Brice
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Pipe command not working

[Jakob Bohm]

On 5/24/2013 8:58 PM, Dave Thompson wrote:



*From:* owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Salz, Rich
*Sent:* Friday, 24 May, 2013 14:05
*To:* openssl-users@openssl.org
*Subject:* RE: Pipe command not working

Windows doesn’t do pipes; you have to use temp files.

Not true. IIRC the original MSDOS-based Windows (3.1, 95, 98) didn't,
but all "NT" series Windows do. I use Windows pipes all the time --
including for the sort of openssl commandline operations OP posted.
One thing to watch out for, though, with C programs (including openssl):



Actually, MS-DOS since version 2.00 did pipes, but it was emulated by 
redirecting output to a temporary file, then when the first program

ended, starting the second program with input redirected from the temp
file, finally deleting the temp file after the second command exited.



For piping one commandline openssl to another, using (as I do) the
ShiningLight build and thus the "visual c++" runtime, it has worked,
but for arbitrary mixtures of other Windows programs I have had issues.



The Visual C++ runtime uses a hidden binary parameter to pass the
text/binary status and native NT handle mapping of each emulated POSIX
file handle to launched programs.  It is possible that the ShiningLight
build has the good fortune of using a Visual C++ runtime which plays
well with the Visual C++ runtime used by the command shell in this
regard.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

SUIT-B implementation

[mehroz]

Hi all, 

i am very new to openssl, or you can say not a user of openssl.
I am facing a scenario where SSL encryption is required at TLS layers for
security purposes.
This belongs to VoIP systems where signalling has to be encrypted.

I have a requirement of doing all encryption in SUIT-B standard. By now, i
have a pre-built scripts that use openssl to generates certs and keys:, The
script is attached  gentls_cert
  

Default set to:
Signature Algorithm: sha1WithRSAEncryption
Public Key Algorithm: rsaEncryption

What do i have to do in order to make encryption according to SUIT-B
standard, and where do i need to look upon.

Thank
Looking forward




--
View this message in context: 
http://openssl.6102.n7.nabble.com/SUIT-B-implementation-tp45318.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org