RE: Client certificate authentication
> From: openssl-users On Behalf Of Viktor > Dukhovni > Sent: Thursday, 11 March, 2021 10:39 > To: openssl-users@openssl.org > Subject: Re: Client certificate authentication > > > On Mar 11, 2021, at 2:16 PM, Robert Ionescu > wrote: > > > > I am searching for the functions in openssl used to verify the clients > > certificate when using mutual authentication. > > My intention is to find a way to log a wrong user certificate directly > inside > > the openssl source. > > What does "wrong" mean? This is an important question. PKIX does not specify the interpretation of the client certificate. While chain construction and most of validity checks (signature, validity dates, basic constraints, KU and EKU, etc) apply, the association between the identity claimed by the certificate and the client is not determined by the standard. Even the form of that association and what is being identified are up to the application. Conventionally, I believe these options are most commonly used: 1. The client certificate identifies the peer system, i.e. the network node that the server is communicating with. This might look symmetric with the client's identification of the server, but it isn't, because a client specifies a server identity (e.g. by hostname) and then verifies that using the server certificate; but in the normal use case, the server has no prior notion of the client system's identity. So the server might get the peer IP address from the stack and then look for an IPADDR SAN in the client's certificate which matches that, for example. The server might also attempt reverse DNS (PTR record) resolution from the IP address to a hostname or FQDN and look for a corresponding DNS SAN or Subject CN, though that option is fraught with potential for abuse. 2. The client certificate identifies the user. Here the certificate is issued to, and identifies, a person or other actor (e.g. the peer application) rather than a network identity. What the server application does with this information is a further question. 3. The client certificate matches a preconfigured allow list: The server application just has some list of "permit any client identified by one of these certificates". 4. The client certificate is validated but beyond that is used as an opaque reference to some other database. This is a variation on #3. IBM's CICS Web Interface provides this mode, where clients can send arbitrary certificates as long as they're valid and belong to a chain that terminates in one of the configured trust anchors. The handshake is completed. Then the system will look that certificate up in the security database to see if it's known and associated with a user identity. If not, the application (or more properly the CWI subsystem) prompts for user credentials using HTTP Basic Authentication (over the TLS channel); if that's successful, the association between client certificate and user account is recorded and the conversation continues. 5. No further vetting of the certificate is done. Essentially the client authentication serves simply as a generic gatekeeper, so that only clients possessing an acceptable certificate are allowed to establish a TLS connection to the server. Any authentication beyond that is handled by the application using other means. So a client certificate can be "wrong" in the basic PKIX sense of "invalid certificate" or "can't build a path", but beyond that the interpretation is up to the server-side application. -- Michael Wojcik
Re: Client certificate authentication
If he's trying to muck with the library, he's probably struggling with a precompiled binary he doesn't have the source code to. -Kyle H On Thu, Mar 11, 2021, 11:48 Viktor Dukhovni wrote: > > On Mar 11, 2021, at 2:16 PM, Robert Ionescu > wrote: > > > > I am searching for the functions in openssl used to verify the clients > > certificate when using mutual authentication. > > The same code verifies peer certificate chains, whether client or server. > > > My intention is to find a way to log a wrong user certificate directly > inside > > the openssl source. > > What does "wrong" mean? OpenSSL is a library, it has no business making > decisions like writing log entries, that's an application prerogative, and > any logging of diagnostic or audit trail events should in application code, > not in OpenSSL library code. > > -- > Viktor. > >
Re: Client certificate authentication
> On Mar 11, 2021, at 2:16 PM, Robert Ionescu > wrote: > > I am searching for the functions in openssl used to verify the clients > certificate when using mutual authentication. The same code verifies peer certificate chains, whether client or server. > My intention is to find a way to log a wrong user certificate directly inside > the openssl source. What does "wrong" mean? OpenSSL is a library, it has no business making decisions like writing log entries, that's an application prerogative, and any logging of diagnostic or audit trail events should in application code, not in OpenSSL library code. -- Viktor.
Client certificate authentication
Hi, I am searching for the functions in openssl used to verify the clients certificate when using mutual authentication. My intention is to find a way to log a wrong user certificate directly inside the openssl source. Any help would be highly appreciated ___ Robert Ionescu *The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.*
Re: Cross-Compiling w/ FIPS Support from Linux to Windows
I'm still struggling with this problem, but I have a little more
information. I learned from a close reading of `INSTALL.W32` and `.W64`
that support for 64-bit Windows is not stable, but support for 32-bit
Windows is okay, and that cross-compilation from Linux is possible. An
example given in `INSTALL.W32` seems to confirm that my environment
variables are close to correct, except for the 32/64-bit differences.
I made another attempt, this time targetting 32-bit Windows. Everything
is the same as my first message, except the environment variables:
```
export MACHINE="MINGW"
export SYSTEM="mingw"
export CROSS_COMPILE="i686-w64-mingw32-"
export HOSTCC="gcc"
export FIPS_SIG="${FIPS_HOME}/src/util/msincore"
```
The FOM build completes as expected, but I encountered [this
problem][0] having to do with multiple definitions. I applied the fix
that the OP describes there (i.e. renaming the offending symbols), and
the build continued. Unfortunately, it seems like nothing has changed,
because I still get the same error as before:
```
no fipstx section at ${FIPS_HOME}/src/util/msincore line 132.
```
If anyone has any information at all about this problem, I would
appreciate it if you sent it along.
Thank you,
Bradley
[0]:
http://openssl.6102.n7.nabble.com/OpenSSL-1-0-1e-build-failure-using-MinGW-multiple-definition-of-OPENSSL-Uplink-td46492.html
signature.asc
Description: This is a digitally signed message part
OpenSSL version 3.0.0-alpha13 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 3.0 alpha 13 released = OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 13 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha13.tar.gz Size: 14211501 SHA1 checksum: 754aab6dc677668255fec676c6340a3a191e8135 SHA256 checksum: c88cbb9d330b4daa3dbb5af1ed511d5062253291a56e09fd17e9ac013a20f8a3 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha13.tar.gz openssl sha256 openssl-3.0.0-alpha13.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmBKH2UACgkQ2cTSbQ5g RJGU0gf9F6POd8koanFFrOBR9BlnlZyhFqYgn0s0404f4FIv0ntX9ClJ/GU4CruD hch4riFzD4uGtX9vpEHMs6cdWmMQmaoQendH0kIbHqLubxm3R51S8L5sIxQRnc0B pXDEteafEPd8jQyZmcg5Hd0aQI1Ju7hw3B9H/0C8JkPbSyfP7XOanWJJh9dinOEb HpswBhQWNmY6OwyIv9mmJQ+BtEbTXrADpMTsBWH1s84oQ8xT64e3Jzkwyx4DDnBi dKDYJjhjAV6mm7GVTBgT3nier3p9CgvbmViMRf1RNbwOpX7lhd+VgWN0QfvOF2dT rKbOZXDnSjbTt2lDr4VvOY+8B870/g== =1LTf -END PGP SIGNATURE-
couldnot upload OBWAC and OBSEAl for openbanking
I am trying to generate a csr file using the config file for openbanking in openssl(1.1.1.j) in windows10 . In newer openssl version OID 2.5.4.97 is reserved for organizationIdentifier, so you can change your obwac.conf by removing the OID and it should work. with OID we are unable to generate the csr file.so by removing the OID i m able to generate the csr file.But as OID is a mandatory in the CSR ,the openbanking is not accepting the certificate.Can some one help??
