strange behavior when EAP is enabled?
I’ve seen a strange one… I’ve created the test certs, etc, that enable the EAP configuration to work. Running radiusd -X, one sees (in relevant part): # Linked to sub-module rlm_eap_tls tls { tls = "tls-common" } tls-config tls-common { verify_depth = 0 ca_path = "/opt/local/etc/raddb/certs" pem_file_type = yes private_key_file = "/opt/local/etc/raddb/certs/server.pem" certificate_file = "/opt/local/etc/raddb/certs/server.pem" ca_file = "/opt/local/etc/raddb/certs/ca.pem" private_key_password = <<< secret >>> dh_file = "/opt/local/etc/raddb/certs/dh" fragment_size = 1024 include_length = yes auto_chain = yes check_crl = no check_all_crl = no cipher_list = "DEFAULT" cipher_server_preference = no ecdh_curve = "prime256v1" tls_max_version = "" tls_min_version = "1.0" cache { enable = no lifetime = 24 max_entries = 255 } verify { skip_if_ocsp_ok = no } ocsp { enable = no override_cert_url = yes url = "http://127.0.0.1/ocsp/" use_nonce = yes timeout = 0 softfail = no } } […] However, if I try to start radiusd as normal (not via -X), I end up with this behavior in the logs: Fri Dec 20 20:46:38 2019 : Error: tls: Failed reading certificate file "/opt/local/etc/raddb/certs/server.pem": error:0906D06C:PEM routines:PEM_read_bio:no start line Fri Dec 20 20:46:38 2019 : Error: rlm_eap_tls: Failed initializing SSL context Fri Dec 20 20:46:38 2019 : Error: rlm_eap (EAP): Failed to initialise rlm_eap_tls Fri Dec 20 20:46:38 2019 : Error: /opt/local/etc/raddb/mods-enabled/eap[14]: Instantiation failed for module “eap" Clearly, I can disable EAP (as I don’t use it at the moment) and get things working; however, I’m trying to disable as little of the default configs as possible. Is there something different in the code path when debugging is enabled vs not that is making OpenSSL libraries do something weird? -- Coy Hile coy.hile@coyhile.com
On Dec 20, 2019, at 3:56 PM, Coy Hile <coy.hile@coyhile.com> wrote:
I’ve seen a strange one… I’ve created the test certs, etc, that enable the EAP configuration to work. Running radiusd -X, one sees (in relevant part): ... However, if I try to start radiusd as normal (not via -X), I end up with this behavior in the logs:
Fri Dec 20 20:46:38 2019 : Error: tls: Failed reading certificate file "/opt/local/etc/raddb/certs/server.pem": error:0906D06C:PEM routines:PEM_read_bio:no start line
That's probably file permissions. OpenSSL is notorious for terrible error messages,
Clearly, I can disable EAP (as I don’t use it at the moment) and get things working; however, I’m trying to disable as little of the default configs as possible. Is there something different in the code path when debugging is enabled vs not that is making OpenSSL libraries do something weird?
If you're running "radiusd -X" as root, and daemon mode as user radiusd, then the issue is likely file permissions. Alan DeKok.
On Dec 20, 2019, at 4:00 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 20, 2019, at 3:56 PM, Coy Hile <coy.hile@coyhile.com> wrote:
I’ve seen a strange one… I’ve created the test certs, etc, that enable the EAP configuration to work. Running radiusd -X, one sees (in relevant part): ... However, if I try to start radiusd as normal (not via -X), I end up with this behavior in the logs:
Fri Dec 20 20:46:38 2019 : Error: tls: Failed reading certificate file "/opt/local/etc/raddb/certs/server.pem": error:0906D06C:PEM routines:PEM_read_bio:no start line
That's probably file permissions. OpenSSL is notorious for terrible error messages,
Clearly, I can disable EAP (as I don’t use it at the moment) and get things working; however, I’m trying to disable as little of the default configs as possible. Is there something different in the code path when debugging is enabled vs not that is making OpenSSL libraries do something weird?
If you're running "radiusd -X" as root, and daemon mode as user radiusd, then the issue is likely file permissions.
My initial thought as well; however, even running as user radiusd, I see the same behavior; starts fine in debug mode, and bails with the cited error. Interestingly, if I run radiusd -f as root, I see the same behavior in the logs and a failure to start. Permissions _should_ be fine: [root@b4eaa42c-a960-e926-9f73-dd4aa748f865 /opt/local/etc/raddb]# ls -ld . certs drwxr-xr-x 9 root root 21 Dec 20 20:07 . drwxr-x--- 2 radiusd radiusd 35 Dec 20 20:45 certs [root@b4eaa42c-a960-e926-9f73-dd4aa748f865 /opt/local/etc/raddb]# root@b4eaa42c-a960-e926-9f73-dd4aa748f865 /opt/local/etc/raddb/certs]# ls -l server.pem -rw-r----- 1 radiusd radiusd 3659 Dec 20 19:59 server.pem [root@b4eaa42c-a960-e926-9f73-dd4aa748f865 /opt/local/etc/raddb/certs]# The file is readable by user ‘radiusd’ Hence my confusion. Clearly the passphrase in the EAP config (‘whatever’) works, else it would fail in debug mode -- Coy Hile coy.hile@coyhile.com
On Dec 20, 2019, at 4:22 PM, Coy Hile <coy.hile@coyhile.com> wrote:
My initial thought as well; however, even running as user radiusd, I see the same behavior; starts fine in debug mode, and bails with the cited error. Interestingly, if I run radiusd -f as root, I see the same behavior in the logs and a failure to start.
Weird.
Permissions _should_ be fine:
Well, I blame some weird Linux stuff. Maybe SELinux? Alan DeKok.
On Dec 20, 2019, at 4:53 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 20, 2019, at 4:22 PM, Coy Hile <coy.hile@coyhile.com> wrote:
My initial thought as well; however, even running as user radiusd, I see the same behavior; starts fine in debug mode, and bails with the cited error. Interestingly, if I run radiusd -f as root, I see the same behavior in the logs and a failure to start.
Weird.
Permissions _should_ be fine:
Well, I blame some weird Linux stuff. Maybe SELinux?
Not in the least; this particular instance is SmartOS, so at least I have good debugging tools (read: Dtrace) to dig deep after the holiday. Once I figure out what’s up, I’ll definitely post the solution back to the list for posterity. I asked here on the off chance that this were something like “Oh, look, the code does <X> strangeness in debug mode.” Appreciate your help, Alan. -- Coy Hile coy.hile@coyhile.com
On Dec 20, 2019, at 5:17 PM, Coy Hile <coy.hile@coyhile.com> wrote:
On Dec 20, 2019, at 4:53 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 20, 2019, at 4:22 PM, Coy Hile <coy.hile@coyhile.com> wrote:
My initial thought as well; however, even running as user radiusd, I see the same behavior; starts fine in debug mode, and bails with the cited error. Interestingly, if I run radiusd -f as root, I see the same behavior in the logs and a failure to start.
Weird.
Permissions _should_ be fine:
Well, I blame some weird Linux stuff. Maybe SELinux?
Not in the least; this particular instance is SmartOS, so at least I have good debugging tools (read: Dtrace) to dig deep after the holiday. Once I figure out what’s up, I’ll definitely post the solution back to the list for posterity. I asked here on the off chance that this were something like “Oh, look, the code does <X> strangeness in debug mode.”
Appreciate your help, Alan.
And, for posterity’s sake, I found the solution here. The server.pem file created by the bootstrap script looks thus: ``` Bag Attributes localKeyID: ... issuer=... -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- Bag Attributes more garbage... -----BEGIN ENCRYPTED PRIVATE KEY----- ... ——END ENCRYPTED PRIVATE KEY—— ``` Once I moved the private key to the top of the file (and removed the Bag attributes information (which I haven’t seen before)), ending up with the server.pem looking thus: ``` ——BEGIN ENCRYPTED PRIVATE KEY----- ... ——END ENCRYPTED PRIVATE KEY----- -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` the world is good to go. (Note Mail.app may have mucked with some formatting there.) -- Coy Hile coy.hile@coyhile.com
On Dec 20, 2019, at 6:27 PM, Coy Hile <coy.hile@coyhile.com> wrote:
And, for posterity’s sake, I found the solution here. The server.pem file created by the bootstrap script looks thus:
``` Bag Attributes localKeyID: ... issuer=... -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- Bag Attributes more garbage... -----BEGIN ENCRYPTED PRIVATE KEY----- ... ——END ENCRYPTED PRIVATE KEY—— ```
Hmm... that's terrible. I think OpenSSL changed that a while back. It's a fairly stupid thing to do, IMHO. If I want the PEM file, I don't care about extra garbage being printed.
Once I moved the private key to the top of the file (and removed the Bag attributes information (which I haven’t seen before)), ending up with the server.pem looking thus:
``` ——BEGIN ENCRYPTED PRIVATE KEY----- ... ——END ENCRYPTED PRIVATE KEY----- -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ```
the world is good to go.
That's good to hear. It's not clear why OpenSSL reads the file one mode but not the other. Alan DeKok.
On Dec 22, 2019, at 12:08 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 20, 2019, at 6:27 PM, Coy Hile <coy.hile@coyhile.com> wrote:
And, for posterity’s sake, I found the solution here. The server.pem file created by the bootstrap script looks thus:
``` Bag Attributes localKeyID: ... issuer=... -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- Bag Attributes more garbage... -----BEGIN ENCRYPTED PRIVATE KEY----- ... ——END ENCRYPTED PRIVATE KEY—— ```
Hmm... that's terrible. I think OpenSSL changed that a while back. It's a fairly stupid thing to do, IMHO. If I want the PEM file, I don't care about extra garbage being printed.
Once I moved the private key to the top of the file (and removed the Bag attributes information (which I haven’t seen before)), ending up with the server.pem looking thus:
``` ——BEGIN ENCRYPTED PRIVATE KEY----- ... ——END ENCRYPTED PRIVATE KEY----- -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ```
the world is good to go.
That's good to hear. It's not clear why OpenSSL reads the file one mode but not the other.
Alan DeKok.
I’ll check later in the week when I’m off to see whether something needs tweaked in the bootstrap and send a PR your way if so. I agree it’s pretty terrible, but it is OpenSSL after all. Said only slightly tongue-in-cheek. -- Coy Hile coy.hile@coyhile.com
participants (2)
-
Alan DeKok -
Coy Hile