radius server presenting itself as 127.0.0.1
Hi all, I'm working on developing a high-availability setup PacketFence, which uses freeradius to authenticate users against our internal active directory server. I've just come to implement the production self-signed certificates as laid out in http://deployingradius.com/documents/configuration/ca_import.html and when I enable the "validate server certificate" box on my windows client I am asked to accept the certificate, which is expected as I haven't deployed the CA certificate yet, however I'm seeing "127.0.0.1" presented as the radius server name in the pop up box, rather than the actual hostname. I can't seem to find why this is happening, and I'd rather that have the server hostnames in the trusted radius server list than something generic like 127.0.0.1. Can anyone please point me in the right direction? Debug log attached. Cheers, Andi
On 03/06/2014 07:05 AM, Morris, Andi wrote:
Hi all,
I'm working on developing a high-availability setup PacketFence, which uses freeradius to authenticate users against our internal active directory server. I've just come to implement the production self-signed certificates as laid out in http://deployingradius.com/documents/configuration/ca_import.html and when I enable the "validate server certificate" box on my windows client I am asked to accept the certificate, which is expected as I haven't deployed the CA certificate yet, however I'm seeing "127.0.0.1" presented as the radius server name in the pop up box, rather than the actual hostname.
I can't seem to find why this is happening, and I'd rather that have the server hostnames in the trusted radius server list than something generic like 127.0.0.1.
Can anyone please point me in the right direction? Debug log attached.
This problem is not likely to be found in the debug log, you need to look at the contents of your certs. % openssl x509 -text -in cert_filename How were your certs generated? Are you using the bootstrap certs? -- John
Hi John, Thanks for your reply. The contents of my server.pem file using the openssl x509 -text -in server.pem file are shows the hostname of the server as I entered into the server.cnf file. The certificates were created by filling in the ca.cnf and server.cnf details and running 'make'. Steps were taken from http://deployingradius.com/documents/configuration/certificates.html However, I've just spotted that I had the same commonName for both my server.cnf and ca.cnf. Just edited the ca.cnf and now make is failing as I need to revoke the previous certificates.....that's proving to be a struggle. Cheers, Andi -----Original Message----- From: freeradius-users-bounces+amorris=cardiffmet.ac.uk@lists.freeradius.org [mailto:freeradius-users-bounces+amorris=cardiffmet.ac.uk@lists.freeradius.org] On Behalf Of John Dennis Sent: 06 March 2014 14:40 To: FreeRadius users mailing list Subject: Re: radius server presenting itself as 127.0.0.1 On 03/06/2014 07:05 AM, Morris, Andi wrote:
Hi all,
I'm working on developing a high-availability setup PacketFence, which uses freeradius to authenticate users against our internal active directory server. I've just come to implement the production self-signed certificates as laid out in http://deployingradius.com/documents/configuration/ca_import.html and when I enable the "validate server certificate" box on my windows client I am asked to accept the certificate, which is expected as I haven't deployed the CA certificate yet, however I'm seeing "127.0.0.1" presented as the radius server name in the pop up box, rather than the actual hostname.
I can't seem to find why this is happening, and I'd rather that have the server hostnames in the trusted radius server list than something generic like 127.0.0.1.
Can anyone please point me in the right direction? Debug log attached.
This problem is not likely to be found in the debug log, you need to look at the contents of your certs. % openssl x509 -text -in cert_filename How were your certs generated? Are you using the bootstrap certs? -- John - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
MA> The contents of my server.pem file using the openssl x509 -text MA> -in server.pem file are shows the hostname of the server as I MA> entered into the server.cnf file. MA> The certificates were created by filling in the ca.cnf and MA> server.cnf details and running 'make'. MA> Steps were taken from MA> http://deployingradius.com/documents/configuration/certificates.html MA> However, I've just spotted that I had the same commonName for MA> both my server.cnf and ca.cnf. Just edited the ca.cnf and now make MA> is failing as I need to revoke the previous MA> certificates.....that's proving to be a struggle. I've been using easy-rsa [part of openvpn] for generating my x509/EAP-TLS certs. It's a lot easier. You might consider it. :) -Greg
Hi,
However, I've just spotted that I had the same commonName for both my server.cnf and ca.cnf. Just edited the ca.cnf and now make is failing as I need to revoke the previous certificates.....that's proving to be a struggle.
start from scratch.... or, if you are just hacking around, delete all the new files that dont exist by default (the .csr, crt, pem, key, serial, etc. should have a directory with just: bootstrap ca.cnf client.cnf Makefile README server.cnf xpextensions now edit the files as required....not, if doing own CA etc then ensure you have all the required extensions in the certs as required by clients....Windows clients need the xpextensions (as will be done by default)...Windows Phone clients (and Win7/Win8) now also need CRLDP to be present (which will it will be - example of - if you get latest sourcecode) alan
On 03/06/2014 10:10 AM, Morris, Andi wrote:
However, I've just spotted that I had the same commonName for both my server.cnf and ca.cnf.
That's a problem and one I've see others make. Any cert whose subject and issuer are identical is considered a self-signed cert and you won't "chain up" to the signing CA cert. It also become ambiguous when both certs are present. Each X509 library may handle this differently so you may get different results depending on the implementation. The simple answer is "don't do it", it just creates problems. FWIW certs are disambiguated by the <subject, serial> pair, CA's are never supposed to issue a cert with a previously used serial number. But the issuer field in a cert only contains a subject, this is why you'll often see the serial embedded in the subject of an issuer cert, it helps to properly identify the correct issuer cert. -- John
Thanks for the replies everyone. The revocation wasn't going as planned so I did as Alan suggested and restored the folder from a backup I made before running the first 'make'. I then edited the ca.cnf to give a different commonName to the server.cnf, ran make again and all went well. However I still am seeing the servername as being 127.0.0.1 on the Windows supplicant. Cheers, Andi -----Original Message----- From: freeradius-users-bounces+amorris=cardiffmet.ac.uk@lists.freeradius.org [mailto:freeradius-users-bounces+amorris=cardiffmet.ac.uk@lists.freeradius.org] On Behalf Of John Dennis Sent: 06 March 2014 15:55 To: FreeRadius users mailing list Subject: Re: radius server presenting itself as 127.0.0.1 On 03/06/2014 10:10 AM, Morris, Andi wrote:
However, I've just spotted that I had the same commonName for both my server.cnf and ca.cnf.
That's a problem and one I've see others make. Any cert whose subject and issuer are identical is considered a self-signed cert and you won't "chain up" to the signing CA cert. It also become ambiguous when both certs are present. Each X509 library may handle this differently so you may get different results depending on the implementation. The simple answer is "don't do it", it just creates problems. FWIW certs are disambiguated by the <subject, serial> pair, CA's are never supposed to issue a cert with a previously used serial number. But the issuer field in a cert only contains a subject, this is why you'll often see the serial embedded in the subject of an issuer cert, it helps to properly identify the correct issuer cert. -- John - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Thanks for the replies everyone. The revocation wasn't going as planned so I did as Alan suggested and restored the folder from a backup I made before running the first 'make'. I then edited the ca.cnf to give a different commonName to the server.cnf, ran make again and all went well. However I still am seeing the servername as being 127.0.0.1 on the Windows supplicant.
well...it probably is! without seeing your config files or certs we cannot help.... alan
That's fair, sorry everyone. Please find cnf files below: Server.cnf: [ ca ] default_ca = CA_default [ CA_default ] dir = ./ certs = $dir crl_dir = $dir/crl database = $dir/index.txt new_certs_dir = $dir certificate = $dir/server.pem serial = $dir/serial crl = $dir/crl.pem private_key = $dir/server.key RANDFILE = $dir/.rand name_opt = ca_default cert_opt = ca_default default_days = 1826 default_crl_days = 30 default_md = sha1 preserve = no policy = policy_match [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] prompt = no distinguished_name = server default_bits = 2048 input_password = password output_password = password [server] countryName = GB stateOrProvinceName = South Glamorgan localityName = Cardiff organizationName = Cardiff Metropolitan University emailAddress = network@cardiffmet.ac.uk commonName = "pfdevll01.internal.uwic.ac.uk" ca.cnf: [ ca ] default_ca = CA_default [ CA_default ] dir = ./ certs = $dir crl_dir = $dir/crl database = $dir/index.txt new_certs_dir = $dir certificate = $dir/ca.pem serial = $dir/serial crl = $dir/crl.pem private_key = $dir/ca.key RANDFILE = $dir/.rand name_opt = ca_default cert_opt = ca_default default_days = 1826 default_crl_days = 30 default_md = sha1 preserve = no policy = policy_match [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] prompt = no distinguished_name = certificate_authority default_bits = 2048 input_password = password output_password = password x509_extensions = v3_ca [certificate_authority] countryName = GB stateOrProvinceName = South Glamorgan localityName = Cardiff organizationName = Cardiff Metropolitan University emailAddress = network@cardiffmet.ac.uk commonName = "pfdevll01 CA" [v3_ca] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always basicConstraints = CA:true openssl x509 -text -in server.pem Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, ST=South Glamorgan, L=Cardiff, O=Cardiff Metropolitan University/emailAddress=networks@cardiffmet.ac.uk, CN=pfdevll01 CA Validity Not Before: Mar 6 16:02:29 2014 GMT Not After : Mar 6 16:02:29 2019 GMT Subject: C=GB, ST=South Glamorgan, O=Cardiff Metropolitan University, CN=pfdevll01.internal.uwic.ac.uk/emailAddress=network@cardiffmet.ac.uk Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ae:a6:39:cc:b9:35:aa:df:a4:33:fb:5c:4f:a5: e9:30:98:38:40:bb:0e:b6:5e:4c:dc:9c:f1:84:35: 21:55:ca:a8:9e:6b:fe:ec:4f:5c:d1:23:de:e7:c1: 00:14:f8:8d:4f:ce:1b:15:b2:a4:61:ea:fe:2c:aa: 3e:9c:c4:a4:bb:be:ac:ed:0b:1c:b1:99:29:00:7b: 14:f7:b1:7f:f4:ea:2e:9b:4d:95:7d:63:6a:99:37: 19:de:85:5a:09:4c:0a:22:25:21:bd:8f:31:08:2e: a4:aa:1c:52:1d:f6:16:19:f8:f7:ed:7b:97:bf:d0: 00:3b:eb:3f:76:e7:41:7c:bd:39:ba:a6:17:a9:1e: 5c:a1:07:a8:14:11:db:eb:9c:cd:4d:f3:3d:8f:2b: f1:6b:5b:55:9c:83:c4:79:d8:90:1a:e0:66:76:d7: 4a:e7:af:68:d7:7f:3b:60:69:9e:c8:a3:b8:c4:e5: f7:38:8b:b8:a6:a6:2b:06:d4:01:73:b4:19:67:ce: 55:6c:8a:90:a8:29:b8:f6:cd:08:b0:3a:eb:18:61: ea:b6:4a:da:8c:bd:11:c8:b9:55:ee:12:57:84:7b: e0:9f:05:4a:11:ef:70:46:77:b9:b1:24:e7:6e:52: 52:e1:76:8a:d5:3b:44:32:f5:70:27:52:b8:dd:ac: 41:b3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Extended Key Usage: TLS Web Server Authentication Signature Algorithm: sha1WithRSAEncryption 43:e8:28:ba:5c:c9:07:dd:08:bb:35:8b:c7:17:c3:88:5d:48: 4e:07:4f:3b:36:55:18:ff:26:58:69:75:5d:33:e8:8f:53:21: 9e:2e:20:5c:16:ec:64:45:07:40:7c:26:8d:5f:cf:a8:9f:75: b0:02:7b:88:7d:eb:e1:40:f2:c5:92:db:a7:43:83:51:72:06: 83:f9:8d:8e:b7:3b:b6:d0:10:6d:12:38:62:c1:1f:4f:da:aa: 7f:52:1b:53:9c:a7:4c:3c:89:d5:19:c7:83:66:cd:79:e6:76: 3a:30:86:66:b9:31:e5:85:48:70:95:94:ac:5f:42:1c:b4:5c: 79:e1:c3:75:98:82:b8:7e:63:33:f5:7d:ec:d2:23:19:33:b8: 30:0d:3f:f8:10:d0:d1:96:8e:45:4f:58:9b:74:2d:c8:ef:a1: fb:d2:37:1f:e0:a1:de:24:e9:09:24:25:5e:ec:95:4f:10:72: 95:b8:35:51:42:b6:16:c3:1c:df:ed:ac:8e:c0:0e:0f:ef:30: 6b:c0:33:8c:6b:b1:c9:ee:6b:e2:87:76:40:62:01:50:6e:f6: ae:b2:66:4f:58:a5:e9:a3:ee:fc:8c:4f:cd:c4:ef:bc:be:f3: e9:f2:38:92:03:52:82:d3:cd:1e:d7:c8:7e:f3:01:50:5f:05: 5e:14:07:28 -----BEGIN CERTIFICATE----- MIID2jCCAsKgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBpDELMAkGA1UEBhMCR0Ix GDAWBgNVBAgTD1NvdXRoIEdsYW1vcmdhbjEQMA4GA1UEBxMHQ2FyZGlmZjEoMCYG A1UEChMfQ2FyZGlmZiBNZXRyb3BvbGl0YW4gVW5pdmVyc2l0eTEoMCYGCSqGSIb3 DQEJARYZbmV0d29ya3NAY2FyZGlmZm1ldC5hYy51azEVMBMGA1UEAxMMcGZkZXZs bDAxIENBMB4XDTE0MDMwNjE2MDIyOVoXDTE5MDMwNjE2MDIyOVowgaIxCzAJBgNV BAYTAkdCMRgwFgYDVQQIEw9Tb3V0aCBHbGFtb3JnYW4xKDAmBgNVBAoTH0NhcmRp ZmYgTWV0cm9wb2xpdGFuIFVuaXZlcnNpdHkxJjAkBgNVBAMTHXBmZGV2bGwwMS5p bnRlcm5hbC51d2ljLmFjLnVrMScwJQYJKoZIhvcNAQkBFhhuZXR3b3JrQGNhcmRp ZmZtZXQuYWMudWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCupjnM uTWq36Qz+1xPpekwmDhAuw62XkzcnPGENSFVyqiea/7sT1zRI97nwQAU+I1PzhsV sqRh6v4sqj6cxKS7vqztCxyxmSkAexT3sX/06i6bTZV9Y2qZNxnehVoJTAoiJSG9 jzEILqSqHFId9hYZ+Pfte5e/0AA76z9250F8vTm6phepHlyhB6gUEdvrnM1N8z2P K/FrW1Wcg8R52JAa4GZ210rnr2jXfztgaZ7Io7jE5fc4i7impisG1AFztBlnzlVs ipCoKbj2zQiwOusYYeq2StqMvRHIuVXuEleEe+CfBUoR73BGd7mxJOduUlLhdorV O0Qy9XAnUrjdrEGzAgMBAAGjFzAVMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA0GCSqG SIb3DQEBBQUAA4IBAQBD6Ci6XMkH3Qi7NYvHF8OIXUhOB087NlUY/yZYaXVdM+iP UyGeLiBcFuxkRQdAfCaNX8+on3WwAnuIfevhQPLFktunQ4NRcgaD+Y2Otzu20BBt EjhiwR9P2qp/UhtTnKdMPInVGceDZs155nY6MIZmuTHlhUhwlZSsX0IctFx54cN1 mIK4fmMz9X3s0iMZM7gwDT/4ENDRlo5FT1ibdC3I76H70jcf4KHeJOkJJCVe7JVP EHKVuDVRQrYWwxzf7ayOwA4P7zBrwDOMa7HJ7mvih3ZAYgFQbvausmZPWKXpo+78 jE/NxO+8vvPp8jiSA1KC080e18h+8wFQXwVeFAco -----END CERTIFICATE----- openssl x509 -text -in ca.pem Certificate: Data: Version: 3 (0x2) Serial Number: 10096988745495451223 (0x8c1fb5c4945f9657) Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, ST=South Glamorgan, L=Cardiff, O=Cardiff Metropolitan University/emailAddress=network@cardiffmet.ac.uk, CN=pfdevll01 CA Validity Not Before: Mar 6 16:02:29 2014 GMT Not After : Mar 6 16:02:29 2019 GMT Subject: C=GB, ST=South Glamorgan, L=Cardiff, O=Cardiff Metropolitan University/emailAddress=network@cardiffmet.ac.uk, CN=pfdevll01 CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:be:82:e5:7d:c0:56:70:8a:29:05:13:a1:f8:a4: 9f:bb:d2:6e:86:83:f5:e0:ae:c8:7b:69:21:66:8b: f8:ec:db:8d:3e:6e:73:50:79:84:83:a3:c9:ea:ed: 1e:65:95:35:52:b5:46:b7:ad:99:c4:ab:62:4c:5e: 3c:80:16:de:81:0f:a1:3c:0f:4c:4d:a9:17:83:15: c5:86:0d:e6:ab:49:7a:f6:f3:a2:cd:ff:89:3d:cb: 81:49:6e:a0:c7:cc:f7:ab:fc:e0:4e:9d:cb:1f:ad: ca:1e:da:4d:41:16:7a:20:d0:72:23:48:75:62:98: aa:36:73:8b:e6:00:7b:41:bc:7e:b4:b5:24:a7:85: 01:d5:2d:c5:8f:f4:69:ff:2b:bb:b8:e1:65:9e:d9: 28:63:cf:45:3e:91:c5:40:ab:c7:3a:95:f6:92:4b: 06:9d:6d:ab:d9:cc:af:49:f4:62:47:7d:89:aa:91: be:f8:1d:a6:2f:03:13:df:87:e6:5f:d1:3e:b3:b7: 8c:d7:f1:bd:5d:3b:53:31:8f:f1:67:d4:31:7d:ce: d3:6e:f7:56:45:ed:90:ba:08:a8:1c:b6:54:4b:c6: d2:d9:e7:8d:ee:f8:23:36:44:49:bc:65:8a:72:18: a9:26:b7:32:f8:ed:b5:db:c3:ce:42:bf:95:3e:f4: c5:ed Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 10:EF:7E:36:8B:B4:AF:F9:13:46:3C:61:54:09:DF:92:1F:58:E1:35 X509v3 Authority Key Identifier: keyid:10:EF:7E:36:8B:B4:AF:F9:13:46:3C:61:54:09:DF:92:1F:58:E1:35 DirName:/C=GB/ST=South Glamorgan/L=Cardiff/O=Cardiff Metropolitan University/emailAddress=networks@cardiffmet.ac.uk/CN=pfdevll01 CA serial:8C:1F:B5:C4:94:5F:96:57 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption 86:c8:5f:5e:fd:ea:e5:4d:c6:c9:14:c1:58:58:53:24:97:d8: 7e:a6:62:ba:ab:00:51:c5:e7:6b:ef:ab:59:b1:d4:dd:c3:f8: a6:05:47:aa:1f:7f:39:64:4b:86:9b:73:a8:57:02:93:99:07: 8d:d3:55:0f:6a:2f:2c:68:d3:9b:7f:42:5a:23:91:36:9f:41: 21:f8:98:b4:70:bf:8b:a7:0a:d8:d3:bb:3a:b1:76:34:91:76: e6:65:ea:4a:ee:5e:9c:cc:93:6a:6a:f1:54:1a:64:08:0c:ff: c9:30:e3:8e:59:61:00:18:a0:c4:7f:54:d2:25:d5:90:77:77: 91:ed:97:1b:33:c8:f6:da:69:eb:af:7f:44:4d:a0:cf:4b:82: aa:f0:08:82:64:b8:a1:5a:39:c0:9f:fc:94:b4:89:c8:5c:0b: 86:f0:e5:df:73:18:f4:74:9b:ba:0e:0d:85:26:81:0a:b4:05: 75:9c:1f:09:8a:f2:8e:97:1b:31:31:7c:4f:0d:c2:11:b3:58: fc:f1:a7:a2:10:8e:21:74:19:fe:68:69:60:6f:44:a3:09:5c: 33:8b:ce:17:5e:b3:da:d9:42:63:84:83:05:34:fb:2a:90:f8: 92:56:5c:80:3c:48:41:15:bf:30:94:f7:ff:82:e8:ca:6d:c1: 64:3b:49:47 -----BEGIN CERTIFICATE----- MIIE3DCCA8SgAwIBAgIJAIwftcSUX5ZXMA0GCSqGSIb3DQEBBQUAMIGkMQswCQYD VQQGEwJHQjEYMBYGA1UECBMPU291dGggR2xhbW9yZ2FuMRAwDgYDVQQHEwdDYXJk aWZmMSgwJgYDVQQKEx9DYXJkaWZmIE1ldHJvcG9saXRhbiBVbml2ZXJzaXR5MSgw JgYJKoZIhvcNAQkBFhluZXR3b3Jrc0BjYXJkaWZmbWV0LmFjLnVrMRUwEwYDVQQD EwxwZmRldmxsMDEgQ0EwHhcNMTQwMzA2MTYwMjI5WhcNMTkwMzA2MTYwMjI5WjCB pDELMAkGA1UEBhMCR0IxGDAWBgNVBAgTD1NvdXRoIEdsYW1vcmdhbjEQMA4GA1UE BxMHQ2FyZGlmZjEoMCYGA1UEChMfQ2FyZGlmZiBNZXRyb3BvbGl0YW4gVW5pdmVy c2l0eTEoMCYGCSqGSIb3DQEJARYZbmV0d29ya3NAY2FyZGlmZm1ldC5hYy51azEV MBMGA1UEAxMMcGZkZXZsbDAxIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAvoLlfcBWcIopBROh+KSfu9JuhoP14K7Ie2khZov47NuNPm5zUHmEg6PJ 6u0eZZU1UrVGt62ZxKtiTF48gBbegQ+hPA9MTakXgxXFhg3mq0l69vOizf+JPcuB SW6gx8z3q/zgTp3LH63KHtpNQRZ6INByI0h1YpiqNnOL5gB7Qbx+tLUkp4UB1S3F j/Rp/yu7uOFlntkoY89FPpHFQKvHOpX2kksGnW2r2cyvSfRiR32JqpG++B2mLwMT 34fmX9E+s7eM1/G9XTtTMY/xZ9Qxfc7TbvdWRe2QugioHLZUS8bS2eeN7vgjNkRJ vGWKchipJrcy+O2128POQr+VPvTF7QIDAQABo4IBDTCCAQkwHQYDVR0OBBYEFBDv fjaLtK/5E0Y8YVQJ35IfWOE1MIHZBgNVHSMEgdEwgc6AFBDvfjaLtK/5E0Y8YVQJ 35IfWOE1oYGqpIGnMIGkMQswCQYDVQQGEwJHQjEYMBYGA1UECBMPU291dGggR2xh bW9yZ2FuMRAwDgYDVQQHEwdDYXJkaWZmMSgwJgYDVQQKEx9DYXJkaWZmIE1ldHJv cG9saXRhbiBVbml2ZXJzaXR5MSgwJgYJKoZIhvcNAQkBFhluZXR3b3Jrc0BjYXJk aWZmbWV0LmFjLnVrMRUwEwYDVQQDEwxwZmRldmxsMDEgQ0GCCQCMH7XElF+WVzAM BgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCGyF9e/erlTcbJFMFYWFMk l9h+pmK6qwBRxedr76tZsdTdw/imBUeqH385ZEuGm3OoVwKTmQeN01UPai8saNOb f0JaI5E2n0Eh+Ji0cL+LpwrY07s6sXY0kXbmZepK7l6czJNqavFUGmQIDP/JMOOO WWEAGKDEf1TSJdWQd3eR7ZcbM8j22mnrr39ETaDPS4Kq8AiCZLihWjnAn/yUtInI XAuG8OXfcxj0dJu6Dg2FJoEKtAV1nB8JivKOlxsxMXxPDcIRs1j88aeiEI4hdBn+ aGlgb0SjCVwzi84XXrPa2UJjhIMFNPsqkPiSVlyAPEhBFb8wlPf/gujKbcFkO0lH -----END CERTIFICATE----- Cheers, Andi -----Original Message----- From: freeradius-users-bounces+amorris=cardiffmet.ac.uk@lists.freeradius.org [mailto:freeradius-users-bounces+amorris=cardiffmet.ac.uk@lists.freeradius.org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: 06 March 2014 16:26 To: FreeRadius users mailing list Subject: Re: radius server presenting itself as 127.0.0.1 Hi,
Thanks for the replies everyone. The revocation wasn't going as planned so I did as Alan suggested and restored the folder from a backup I made before running the first 'make'. I then edited the ca.cnf to give a different commonName to the server.cnf, ran make again and all went well. However I still am seeing the servername as being 127.0.0.1 on the Windows supplicant.
well...it probably is! without seeing your config files or certs we cannot help.... alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Gregory Sloop -
John Dennis -
Morris, Andi