RE: How to create indirect CRL using openssl ca command
> From: openssl-users On Behalf Of > Michael Ströder via openssl-users > Sent: Thursday, 10 March, 2022 12:17 > > On 3/10/22 14:06, edr dr wrote: > > At the same time, I do not want to store passwords used for > > certificate creation in cleartext anywhere. Personally, I'd be leery of using openssl ca for anything other than dev/test purposes, in which case frequent CRL generation seems unlikely to be a requirement. AIUI, openssl ca isn't really intended for production use. > It's a pity that there is not something like an OpenSSL key agent > (similar to ssh-agent) for interactively loading the CA's private key > into memory during service start. To be fair, this is not an OpenSSL limitation; it's a limitation of openssl, the utility. Which, again, is not intended to solve all production use cases. openssl ca, like most openssl subcommands, allows the use of an engine (or provider in 3.0), which means in many cases it's possible to use an inexpensive USB-attached HSM (via the pkcs11 engine) rather than having an on-disk key in the first place. I did this some years ago as an experiment using a NitroKey and it worked well. -- Michael Wojcik
Re: How to create indirect CRL using openssl ca command
On 3/10/22 14:06, edr dr wrote: I would like to be able to automate the process of updating CRLs in order to be able to keep the CRL validity time short. Understandable. At the same time, I do not want to store passwords used for certificate creation in cleartext anywhere. It's a pity that there is not something like an OpenSSL key agent (similar to ssh-agent) for interactively loading the CA's private key into memory during service start. My current approach to achieve this is a separate CA only responsible for revocation. My understanding is that such a CA is called an "indirect CRL issuer" Are you 100% sure all the software used by your relying participants is capable of handling the X509v3 extensions involved? In practice I saw software miserably fail validating such certs and CRLs. Or also CAs failed to generate the certs and CRLs correctly. :-/ Ciao, Michael.
How to create indirect CRL using openssl ca command
Dear all, I am building a private PKI using the openssl "ca" functionality. My setup includes a root CA that issues intermediate certificates and intermediate CAs issuing endpoint certificates. I would like to be able to automate the process of updating CRLs in order to be able to keep the CRL validity time short. At the same time, I do not want to store passwords used for certificate creation in cleartext anywhere. My current approach to achieve this is a separate CA only responsible for revocation. My understanding is that such a CA is called an "indirect CRL issuer" so I'll refer to this separate CA in my setup as "indirect-revoker". The indirect-revoker needs to be able to revoke intermediate certificates issued by the root CA as well as endpoint certificates issued by the intermediate CAs. This is what I did configuration-wise: I referred to the indirect-revoker in the crlDistributionPoints setting as follows: crlDistributionPoints = my_cdp ... [ my_cdp ] fullname = URI:file:///home/me/tmp/ca3/intermediate/indirect-revoker/crl/ca.crl.pem CRLissuer = dirName:crl_issuer_section [ crl_issuer_section ] C = DE O = My Organization OU = My organizational unit CN = indirect-revoker The generated certs contain the desired information, so that seems okay: $ openssl x509 -in ~/tmp/ca3/intermediate/revoked/certs/ca.cert.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 4097 (0x1001) Signature Algorithm: sha256WithRSAEncryption Issuer: C = DE, O = My Organization, OU = My organizational unit, CN = rootca Validity Not Before: Mar 10 12:37:52 2022 GMT Not After : Feb 14 12:37:52 2122 GMT Subject: C = DE, O = My Organization, OU = My organizational unit, CN = revoked Subject Public Key Info: ... X509v3 extensions: X509v3 CRL Distribution Points: Full Name: URI:file:///home/me/tmp/ca3/intermediate/indirect-revoker/crl/ca.crl.pem CRL Issuer: DirName:C = DE, O = My Organization, OU = My organizational unit, CN = indirect-revoker Signature Algorithm: sha256WithRSAEncryption To activate the indirect CRL mode I have added the following crl extensions to indirect-revoker's config: crl_extensions= crl_ext [ crl_ext ] authorityKeyIdentifier=keyid:always issuingDistributionPoint = critical, @idp_section [idp_section] indirectCRL = TRUE This seems to work so far, or at least it is included in the text output of crls generated that way: $ openssl crl -in crl/ca.crl.pem -text -noout Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: C = DE, O = My Organization, OU = My organizational unit, CN = indirect-revoker Last Update: Mar 10 10:32:30 2022 GMT Next Update: Apr 9 10:32:30 2022 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:50:54:61:18:41:51:EF:1A:08:CA:D7:CF:B7:4F:C7:05:B8:C3:41:D1 X509v3 Issuing Distribution Point: critical Indirect CRL X509v3 CRL Number: 4096 Revoked Certificates: Serial Number: 1001 Revocation Date: Mar 10 10:32:30 2022 GMT Signature Algorithm: sha256WithRSAEncryption ... Now section 5.3.3 in RFC 5280 [1] states that crl entries in indirect CRLs need to include the information which CA issued the revoked certificate. As can be seen in the text output above the CRL Entry only contains the CRL Number but not the certificate issuer, which I believe is needed to properly match the CRL entry to the revoked certificate. Sure enough the verification still recognizes revoked certs included in the crl as valid: $ openssl verify -CAfile ~/tmp/ca3/rootca/certs/ca.cert.pem -CRLfile ~/tmp/ca3/intermediate/indirect-revoker/crl/ca.crl.pem ~/tmp/ca3/intermediate/revoked/certs/ca.cert.pem /home/me/tmp/ca3/intermediate/revoked/certs/ca.cert.pem: OK So my question is: how do I get this piece of information into the CRL? The openssl documentation [2] explicitly states that the -crlexts option is not meant for this: "The CRL extensions specified are CRL extensions and not CRL entry extensions. " I could not find any other options that looked appropriate. I also inspected the openssl source code [3] and it looks to me as if the filename of the revoked certificate is never written to the "index" file, so I do not think that it can simply be read from the revoked certificate upon CRL generation. What am I missing? Any hints would be greatly appreciated! Kind regards, edr [1] https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.3 [2] https://www.openssl.org/docs/man3.0/man1/openssl-ca.html [3] https://github.com/openssl/openssl/blob/5979596247a73d1a
RE: SSL_TLSEXT_ERR_NOACK not working as expected
Both solutions work, thanks! -Original Message- From: Matt Caswell Sent: Thursday, 10 March 2022 13:51 To: Tal Dery ; openssl-users@openssl.org Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected On 10/03/2022 11:33, Tal Dery wrote: > I am developing a MITM proxy server, > but in the case of some SNI I am interested in transferring the ClientHello > as it is to the target server and actually making a transparent proxy. > Therefore, I cannot send ServerHello to the client. > I see. There isn't a supported way to abort the handshake without sending an alert (because in the normal course of events you're really not supposed to do that). There *is* actually an undocumented way to achieve this - but I would consider this an accident of the implementation rather than behaviour that you can rely on. Populate the int pointed at by "al" with the value -1 before returning SSL_TLSEXT_ERR_ALERT_FATAL. This is an internal-only value meaning "no alert". Another way to achieve the same goal in a probably more robust way would be to use the null BIO (BIO_s_null). In the tlsext_servername callback, change the write BIO for the SSL object (SSL_set0_wbio) to the null BIO causing all subsequent writes to just "disappear". Matt > > -Original Message- > From: Matt Caswell > Sent: Thursday, 10 March 2022 13:25 > To: Tal Dery ; openssl-users@openssl.org > Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected > > > > On 10/03/2022 11:21, Tal Dery wrote: >> Hi Matt, >> Yes, I want to abort the session without notifying the client. >> SSL_TLSEXT_ERR_ALERT_FATAL sent " 15 03 03 00 02 02 00" to client. >> What can I do to not send the message? > > You want to abort the handshake without sending an alert? That would be a > protocol violation. Don't do that. > > Matt > > > >> >> Thanks >> >> >> -Original Message- >> From: Matt Caswell >> Sent: Thursday, 10 March 2022 12:54 >> To: Tal Dery ; openssl-users@openssl.org >> Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected >> >> >> >> On 10/03/2022 10:26, Tal Dery wrote: >>> Hi, >>> >>> I am implementing an SSL server. >>> >>> Using SSL_CTX_set_tlsext_servername_callback I'm checking the SNI. >>> >>> When SNI meets my requirements (for example does not contain >>> offensive >>> words) I allow the handshake by returning SSL_TLSEXT_ERR_OK. >>> >>> When there is an offensive word, I do not want to send Server Hello >>> message. I try to do this by returning SSL_TLSEXT_ERR_NOACK. >> >> If you don't want the ServerHello to be sent then you are aborting the >> handshake. In that case you should return SSL_TLSEXT_ERR_ALERT_FATAL. By >> comparison SSL_TLSEXT_ERR_NOACK is a non-fatal return code. The SNI request >> is not acknowledged by the server (i.e. it acts the same way as if SNI was >> not configured on the server at all), but no alerts are sent so the >> handshake proceeds as normal. >> >> Matt >> >> >> >>> >>> For some reason, the server is still sending the message, and I wonder why? >>> >>> SSL_TLSEXT_ERR_ALERT_WARNING works as expected. >>> >>> I'm using OpenSSL 1.1.1f and Wireshark to verify what I say. >>> >>> Thanks >>> >> >> >> > > >
Re: SSL_TLSEXT_ERR_NOACK not working as expected
On 10/03/2022 11:33, Tal Dery wrote: I am developing a MITM proxy server, but in the case of some SNI I am interested in transferring the ClientHello as it is to the target server and actually making a transparent proxy. Therefore, I cannot send ServerHello to the client. I see. There isn't a supported way to abort the handshake without sending an alert (because in the normal course of events you're really not supposed to do that). There *is* actually an undocumented way to achieve this - but I would consider this an accident of the implementation rather than behaviour that you can rely on. Populate the int pointed at by "al" with the value -1 before returning SSL_TLSEXT_ERR_ALERT_FATAL. This is an internal-only value meaning "no alert". Another way to achieve the same goal in a probably more robust way would be to use the null BIO (BIO_s_null). In the tlsext_servername callback, change the write BIO for the SSL object (SSL_set0_wbio) to the null BIO causing all subsequent writes to just "disappear". Matt -Original Message- From: Matt Caswell Sent: Thursday, 10 March 2022 13:25 To: Tal Dery ; openssl-users@openssl.org Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected On 10/03/2022 11:21, Tal Dery wrote: Hi Matt, Yes, I want to abort the session without notifying the client. SSL_TLSEXT_ERR_ALERT_FATAL sent " 15 03 03 00 02 02 00" to client. What can I do to not send the message? You want to abort the handshake without sending an alert? That would be a protocol violation. Don't do that. Matt Thanks -Original Message- From: Matt Caswell Sent: Thursday, 10 March 2022 12:54 To: Tal Dery ; openssl-users@openssl.org Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected On 10/03/2022 10:26, Tal Dery wrote: Hi, I am implementing an SSL server. Using SSL_CTX_set_tlsext_servername_callback I'm checking the SNI. When SNI meets my requirements (for example does not contain offensive words) I allow the handshake by returning SSL_TLSEXT_ERR_OK. When there is an offensive word, I do not want to send Server Hello message. I try to do this by returning SSL_TLSEXT_ERR_NOACK. If you don't want the ServerHello to be sent then you are aborting the handshake. In that case you should return SSL_TLSEXT_ERR_ALERT_FATAL. By comparison SSL_TLSEXT_ERR_NOACK is a non-fatal return code. The SNI request is not acknowledged by the server (i.e. it acts the same way as if SNI was not configured on the server at all), but no alerts are sent so the handshake proceeds as normal. Matt For some reason, the server is still sending the message, and I wonder why? SSL_TLSEXT_ERR_ALERT_WARNING works as expected. I'm using OpenSSL 1.1.1f and Wireshark to verify what I say. Thanks
RE: SSL_TLSEXT_ERR_NOACK not working as expected
I am developing a MITM proxy server, but in the case of some SNI I am interested in transferring the ClientHello as it is to the target server and actually making a transparent proxy. Therefore, I cannot send ServerHello to the client. -Original Message- From: Matt Caswell Sent: Thursday, 10 March 2022 13:25 To: Tal Dery ; openssl-users@openssl.org Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected On 10/03/2022 11:21, Tal Dery wrote: > Hi Matt, > Yes, I want to abort the session without notifying the client. > SSL_TLSEXT_ERR_ALERT_FATAL sent " 15 03 03 00 02 02 00" to client. > What can I do to not send the message? You want to abort the handshake without sending an alert? That would be a protocol violation. Don't do that. Matt > > Thanks > > > -Original Message- > From: Matt Caswell > Sent: Thursday, 10 March 2022 12:54 > To: Tal Dery ; openssl-users@openssl.org > Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected > > > > On 10/03/2022 10:26, Tal Dery wrote: >> Hi, >> >> I am implementing an SSL server. >> >> Using SSL_CTX_set_tlsext_servername_callback I'm checking the SNI. >> >> When SNI meets my requirements (for example does not contain >> offensive >> words) I allow the handshake by returning SSL_TLSEXT_ERR_OK. >> >> When there is an offensive word, I do not want to send Server Hello >> message. I try to do this by returning SSL_TLSEXT_ERR_NOACK. > > If you don't want the ServerHello to be sent then you are aborting the > handshake. In that case you should return SSL_TLSEXT_ERR_ALERT_FATAL. By > comparison SSL_TLSEXT_ERR_NOACK is a non-fatal return code. The SNI request > is not acknowledged by the server (i.e. it acts the same way as if SNI was > not configured on the server at all), but no alerts are sent so the handshake > proceeds as normal. > > Matt > > > >> >> For some reason, the server is still sending the message, and I wonder why? >> >> SSL_TLSEXT_ERR_ALERT_WARNING works as expected. >> >> I'm using OpenSSL 1.1.1f and Wireshark to verify what I say. >> >> Thanks >> > > >
Re: SSL_TLSEXT_ERR_NOACK not working as expected
On 10/03/2022 11:21, Tal Dery wrote: Hi Matt, Yes, I want to abort the session without notifying the client. SSL_TLSEXT_ERR_ALERT_FATAL sent " 15 03 03 00 02 02 00" to client. What can I do to not send the message? You want to abort the handshake without sending an alert? That would be a protocol violation. Don't do that. Matt Thanks -Original Message- From: Matt Caswell Sent: Thursday, 10 March 2022 12:54 To: Tal Dery ; openssl-users@openssl.org Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected On 10/03/2022 10:26, Tal Dery wrote: Hi, I am implementing an SSL server. Using SSL_CTX_set_tlsext_servername_callback I'm checking the SNI. When SNI meets my requirements (for example does not contain offensive words) I allow the handshake by returning SSL_TLSEXT_ERR_OK. When there is an offensive word, I do not want to send Server Hello message. I try to do this by returning SSL_TLSEXT_ERR_NOACK. If you don't want the ServerHello to be sent then you are aborting the handshake. In that case you should return SSL_TLSEXT_ERR_ALERT_FATAL. By comparison SSL_TLSEXT_ERR_NOACK is a non-fatal return code. The SNI request is not acknowledged by the server (i.e. it acts the same way as if SNI was not configured on the server at all), but no alerts are sent so the handshake proceeds as normal. Matt For some reason, the server is still sending the message, and I wonder why? SSL_TLSEXT_ERR_ALERT_WARNING works as expected. I'm using OpenSSL 1.1.1f and Wireshark to verify what I say. Thanks
RE: SSL_TLSEXT_ERR_NOACK not working as expected
Hi Matt, Yes, I want to abort the session without notifying the client. SSL_TLSEXT_ERR_ALERT_FATAL sent " 15 03 03 00 02 02 00" to client. What can I do to not send the message? Thanks -Original Message- From: Matt Caswell Sent: Thursday, 10 March 2022 12:54 To: Tal Dery ; openssl-users@openssl.org Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected On 10/03/2022 10:26, Tal Dery wrote: > Hi, > > I am implementing an SSL server. > > Using SSL_CTX_set_tlsext_servername_callback I'm checking the SNI. > > When SNI meets my requirements (for example does not contain offensive > words) I allow the handshake by returning SSL_TLSEXT_ERR_OK. > > When there is an offensive word, I do not want to send Server Hello > message. I try to do this by returning SSL_TLSEXT_ERR_NOACK. If you don't want the ServerHello to be sent then you are aborting the handshake. In that case you should return SSL_TLSEXT_ERR_ALERT_FATAL. By comparison SSL_TLSEXT_ERR_NOACK is a non-fatal return code. The SNI request is not acknowledged by the server (i.e. it acts the same way as if SNI was not configured on the server at all), but no alerts are sent so the handshake proceeds as normal. Matt > > For some reason, the server is still sending the message, and I wonder why? > > SSL_TLSEXT_ERR_ALERT_WARNING works as expected. > > I'm using OpenSSL 1.1.1f and Wireshark to verify what I say. > > Thanks >
Re: SSL_TLSEXT_ERR_NOACK not working as expected
On 10/03/2022 10:26, Tal Dery wrote: Hi, I am implementing an SSL server. Using SSL_CTX_set_tlsext_servername_callback I'm checking the SNI. When SNI meets my requirements (for example does not contain offensive words) I allow the handshake by returning SSL_TLSEXT_ERR_OK. When there is an offensive word, I do not want to send Server Hello message. I try to do this by returning SSL_TLSEXT_ERR_NOACK. If you don't want the ServerHello to be sent then you are aborting the handshake. In that case you should return SSL_TLSEXT_ERR_ALERT_FATAL. By comparison SSL_TLSEXT_ERR_NOACK is a non-fatal return code. The SNI request is not acknowledged by the server (i.e. it acts the same way as if SNI was not configured on the server at all), but no alerts are sent so the handshake proceeds as normal. Matt For some reason, the server is still sending the message, and I wonder why? SSL_TLSEXT_ERR_ALERT_WARNING works as expected. I'm using OpenSSL 1.1.1f and Wireshark to verify what I say. Thanks
SSL_TLSEXT_ERR_NOACK not working as expected
Hi, I am implementing an SSL server. Using SSL_CTX_set_tlsext_servername_callback I'm checking the SNI. When SNI meets my requirements (for example does not contain offensive words) I allow the handshake by returning SSL_TLSEXT_ERR_OK. When there is an offensive word, I do not want to send Server Hello message. I try to do this by returning SSL_TLSEXT_ERR_NOACK. For some reason, the server is still sending the message, and I wonder why? SSL_TLSEXT_ERR_ALERT_WARNING works as expected. I'm using OpenSSL 1.1.1f and Wireshark to verify what I say. Thanks
