Re: Client certificate authentication
Hmm ok I get it. So, to be able to get the fingerprint for the used certificates during a TLS handshake is possible by using the SSL_set_verify callbacks in the application or is the mentioned postfix useful for this purpose? ___ 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.* On Mon, Mar 15, 2021 at 12:46 PM Viktor Dukhovni wrote: > On Mon, Mar 15, 2021 at 12:23:54PM +0100, Robert Ionescu wrote: > > > I already found the callbacks for the verification process and I am > > still trying to figure it out if it is possible to change them in a > > way that they will print some certificate information to determine > > which certificate was used? > > What do you mean "change them"? These are callbacks, you register the > callback function in the application, and then do whatever you want in > that function, including print certificate information, if that's your > goal. There's nothing to "change". > > The verification Postfix uses for optional certificate verification > verbosity is at: > > > https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L139-L185 > > -- > Viktor. >
Re: Client certificate authentication
On Mon, Mar 15, 2021 at 12:23:54PM +0100, Robert Ionescu wrote: > I already found the callbacks for the verification process and I am > still trying to figure it out if it is possible to change them in a > way that they will print some certificate information to determine > which certificate was used? What do you mean "change them"? These are callbacks, you register the callback function in the application, and then do whatever you want in that function, including print certificate information, if that's your goal. There's nothing to "change". The verification Postfix uses for optional certificate verification verbosity is at: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L139-L185 -- Viktor.
Re: Client certificate authentication
I already found the callbacks for the verification process and I am still trying to figure it out if it is possible to change them in a way that they will print some certificate information to determine which certificate was used? ___ 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.* On Fri, Mar 12, 2021 at 3:39 PM Viktor Dukhovni wrote: > On Fri, Mar 12, 2021 at 09:06:57AM +0100, Robert Ionescu wrote: > > > With "wrong" certificate I meant "invalid certificate". So the idea > > was in a bigger environment with a lot of certificates, to make the > > invalid certificate debugging easier by getting more information from > > openssl to identify the invalid certificate easier. > > Informal words like "wrong" or "invalid" still don't convey the actual > meaning you have in mind, but in any case, the OpenSSL library provides > callbacks that you can use to track the progress of and report errors > in the certificate verification process. > > SSL_CTX_set_verify(3) > SSL_set_verify(3) > > -- > Viktor. >
Re: Client certificate authentication
On Fri, Mar 12, 2021 at 09:06:57AM +0100, Robert Ionescu wrote: > With "wrong" certificate I meant "invalid certificate". So the idea > was in a bigger environment with a lot of certificates, to make the > invalid certificate debugging easier by getting more information from > openssl to identify the invalid certificate easier. Informal words like "wrong" or "invalid" still don't convey the actual meaning you have in mind, but in any case, the OpenSSL library provides callbacks that you can use to track the progress of and report errors in the certificate verification process. SSL_CTX_set_verify(3) SSL_set_verify(3) -- Viktor.
Re: Client certificate authentication
With "wrong" certificate I meant "invalid certificate". So the idea was in a bigger environment with a lot of certificates, to make the invalid certificate debugging easier by getting more information from openssl to identify the invalid certificate easier. My research is based on this reported issue https://github.com/haproxy/haproxy/issues/693 ___ 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.* On Thu, Mar 11, 2021 at 8:40 PM Michael Wojcik < michael.woj...@microfocus.com> wrote: > > 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 < > hightronicdes...@gmail.com> > > 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
> 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.
Re: Client Certificate Authentication
[EMAIL PROTECTED] wrote: Is there a (reasonable) way to authenticate a client (browser) certificate from a CGI without having to modify the web server configuration. What we are up against is that we produce a package that is supported on a variety of platforms and web servers. We have been informed the to meet security requirements we have to do a public-private key authentication of the user. Thanks in advance for any insights or direction. I'll give it a try and hope someone else will tell me when I'm wrong. I don't think that you can activate client authentication without modifying whe web server configuration, since client authentication has to be requested during SSL handshake. To request a client cert you either have to know what you want before the connection is opened or you'll have to re-negotiate. So since you (that is the CGI-script) do not handle the low level SSL-connection you'll need a way to tell the webserver that it should request a certificate from the client, and I doubt that you can do this if the server is not already configured to at least accept client certs. Also I doubt that in your situation the CGI script can decide which certificate is valid since that should be a decision of the server's hostmaster and is usually handled by configuring the web server to use a certain list of root CAs. --Richard Hope it helps, Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Re: Client Certificate Authentication
Benjamin Grosman [EMAIL PROTECTED]: I am able to fetch the issue and subject details of the client certificate from inside the server, but how do I know that someone hasn't simply generated their own certificate with the same details? If you initialize the verification settings with about the following call sequence, then your server won't even accept connections from clients that don't have a valid certificate directly issued from one of those CAs the self-signed certificates of which are collected in the file named by "ca_certificate_file": static long context_num = 0; SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, (int (*)(int, X509_STORE_CTX *)) 0); ++context_num; r = SSL_CTX_set_session_id_context(ssl_ctx, (void *) context_num, (unsigned int) sizeof context_num); if (!r) ... /* error */ r = SSL_CTX_load_verify_locations(ssl_ctx, ca_certificate_file, NULL); if (!r) ... /* error */ SSL_CTX_set_client_CA_list(ssl_ctx, SSL_load_client_CA_file(ca_certificate_file); SSL_CTX_set_verify_depth(ssl_ctx, 1); Note that SSL_CTX_set_verify_depth is available only in the current snapshot, but not in previous versions. Since, as far as I can see, the internal verification function does not yet properly check whether intermediate CAs are really certified to act as CAs, you have to set the verification depth to 1 to disallow certificate owners to sign certificates at deeper levels -- otherwise they could create their own certificates with different subject names. This would not open up your server to people who don't have an accepted certificate in the first place, but they could pretend to be someone else. You can also write various callback functions related to certificate verification and tell the library to call them, but then things become more involved. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
