PfSense 2.4.3 New Install HTTPS ERR_SSL_BAD_RECORD_MAC_ALERT
-
Brand new install of 2.4.3 on a fresh disk from ISO image download.
Install goes off without a problem.
System reboots.
"Inside" interface gets IP address 192.168.1.1. I change it because I already have a gateway at that address. Change is successful.
Attempt to log into the web interface returns the same error on all browsers: ERR_SSL_BAD_RECORD_MAC_ALERTThis is where it goes from bad to worse.
Revert the web interface to http://192.168.1.222, not https.
Log into web interface. Success.
Configure a new gateway (for now) 192.168.1.1
Test gateway with a dns lookup. Success.
Attempt to update package lists fail. "unable to retrieve package information"Attempt to use curl to download a new package database fails with ERR_SSL_BAD_RECORD_MAC_ALERT
Add LDAP auth over SSL to the firewall also fails with ERR_SSL_BAD_RECORD_MAC_ALERT
So, I can't install a couple of packages I need and I can't run the web interface over ssl, can't do single sign-on.
Ideas?
-
Here is what openssl s_client returns:
openssl s_client -connect 192.168.1.155:443
CONNECTED(00000003)
depth=0 C = US, ST = State, L = Locality, O = pfSense webConfigurator Self-Signed Certificate, emailAddress = admin@pfSense.localdomain, CN = pfSense-5b03418562073
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = State, L = Locality, O = pfSense webConfigurator Self-Signed Certificate, emailAddress = admin@pfSense.localdomain, CN = pfSense-5b03418562073
verify error:num=21:unable to verify the first certificate
verify return:1
140579908155280:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1493:SSL alert number 20
140579908155280:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
–-
Certificate chain
0 s:/C=US/ST=State/L=Locality/O=pfSense webConfigurator Self-Signed Certificate/emailAddress=admin@pfSense.localdomain/CN=pfSense-5b03418562073
i:/C=US/ST=State/L=Locality/O=pfSense webConfigurator Self-Signed Certificate/emailAddress=admin@pfSense.localdomain/CN=pfSense-5b03418562073Server certificate
-----BEGIN CERTIFICATE-----
MIIFjzCCBHegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBtDELMAkGA1UEBhMCVVMx
DjAMBgNVBAgTBVN0YXRlMREwDwYDVQQHEwhMb2NhbGl0eTE4MDYGA1UEChMvcGZT
ZW5zZSB3ZWJDb25maWd1cmF0b3IgU2VsZi1TaWduZWQgQ2VydGlmaWNhdGUxKDAm
BgkqhkiG9w0BCQEWGWFkbWluQHBmU2Vuc2UubG9jYWxkb21haW4xHjAcBgNVBAMT
FXBmU2Vuc2UtNWIwMzQxODU2MjA3MzAeFw0xODA1MjEyMjAwMzhaFw0yMzExMTEy
MjAwMzhaMIG0MQswCQYDVQQGEwJVUzEOMAwGA1UECBMFU3RhdGUxETAPBgNVBAcT
CExvY2FsaXR5MTgwNgYDVQQKEy9wZlNlbnNlIHdlYkNvbmZpZ3VyYXRvciBTZWxm
LVNpZ25lZCBDZXJ0aWZpY2F0ZTEoMCYGCSqGSIb3DQEJARYZYWRtaW5AcGZTZW5z
ZS5sb2NhbGRvbWFpbjEeMBwGA1UEAxMVcGZTZW5zZS01YjAzNDE4NTYyMDczMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvmrJ+G95XA+tbUnvpuEbFABJ
gruxxY41jpAtJwGRNgEKgYxDw9Aq/Fj096ed6or9J4qHTDB4lwijOwWmfVi3zgCw
TaAjObYoqIpiuycJc1jXz82QdsR8yJbNb5U7N/IvAKNxTXsAES3cGO3mVcd875js
K03ghmlu3vH2FfIqCGnV6bUbJpkEt0vjBcrfT6MNqPINf7L5ChHigOQV5me3Umtb
LE3m8s6/heyl6ZeQPiKqFCspnonFDZBf5nwNSo47JodoZ4qbIDWLFraSzrvEsCj9
pIg1bnqBhXpOiylpP2qXISze47oJR83HSb3rPF61bgcgW+4mREaxGdNMaIBmuwID
AQABo4IBqDCCAaQwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBkAwCwYDVR0P
BAQDAgWgMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBTZXJ2ZXIg
Q2VydGlmaWNhdGUwHQYDVR0OBBYEFO5Ijyu3pThn+PQtgJu+hdeAkCNJMIHhBgNV
HSMEgdkwgdaAFO5Ijyu3pThn+PQtgJu+hdeAkCNJoYG6pIG3MIG0MQswCQYDVQQG
EwJVUzEOMAwGA1UECBMFU3RhdGUxETAPBgNVBAcTCExvY2FsaXR5MTgwNgYDVQQK
Ey9wZlNlbnNlIHdlYkNvbmZpZ3VyYXRvciBTZWxmLVNpZ25lZCBDZXJ0aWZpY2F0
ZTEoMCYGCSqGSIb3DQEJARYZYWRtaW5AcGZTZW5zZS5sb2NhbGRvbWFpbjEeMBwG
A1UEAxMVcGZTZW5zZS01YjAzNDE4NTYyMDczggEAMB0GA1UdJQQWMBQGCCsGAQUF
BwMBBggrBgEFBQgCAjAgBgNVHREEGTAXghVwZlNlbnNlLTViMDM0MTg1NjIwNzMw
DQYJKoZIhvcNAQELBQADggEBAAxyAuipxjD8I6NL3oRRUBH8Qglg2uWuUVg27Qkc
Qk0ISsUE3LhOGz2/RtFJQ76+yKcDmG9A6rpl6feAD2cJ6NQToiZFmC/Roc2XF0W/
2ZxPK4VpDwAVg/2aRD0goIbHGfv1jtzYdxCuH7CXEVlD7lZAZVE2UaKprUJusjMe
g9CAFmgNQedQ1AQYV49vpC5EZgQYNJL8Axfl1h6aacl9YDOFSG+gpSWl2Gi2myuJ
Qg5M73uJOvdgWaraXA69jflhk/hXvi0OtKdRbz9qUrkpyreVM25UdOk7dB+9gMPd
9nAVr1v1/r6O02CQF06tC+lX5DrCVpM0rKrT9VepmucUUpc=
-----END CERTIFICATE-----
subject=/C=US/ST=State/L=Locality/O=pfSense webConfigurator Self-Signed Certificate/emailAddress=admin@pfSense.localdomain/CN=pfSense-5b03418562073
issuer=/C=US/ST=State/L=Locality/O=pfSense webConfigurator Self-Signed Certificate/emailAddress=admin@pfSense.localdomain/CN=pfSense-5b03418562073No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bitsSSL handshake has read 1895 bytes and written 126 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 3076F7E9E5F735994F187CCBBA310C4B74B870F62F84B0BED48689CACF282BDD
Session-ID-ctx:
Master-Key: 08E85B0FD894E04438023D3E051209F39D029CE83542E8D810A9F5ABF9FEE1BFC387B6A0F5ADC8809EB24B8AC7F6C0E8
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1526948144
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate) -
I think I figured it out.
pfSense is running on kvm/qemu via libvirt.
Underlying CPU has no aes-ni support. Therefore no aes-ni support is passed through.
Yet, the installer just goes ahead and installs.
Anyone know if this sounds likely?
-
pfSense is running on kvm/qemu via libvirt.
That nugget would have been helpful to know in your first post.
Therefore no aes-ni support is passed through. Yet, the installer just goes ahead and installs.
You say that like it's unexpected behaviour. pfSense is not yet reliant on AES-NI, so you can't expect the installer to warn you about it.
And no, that isn't your problem. You don't need AES-NI to do SSL.
"Inside" interface gets IP address 192.168.1.1. I change it because I already have a gateway at that address.
What do you mean "inside"? You typically have one WAN and one or more LANs. LANs don't usually "get" anything, so I'm assuming you mean WAN? And you already have another WAN at 192.168.1.1?
-
Virtual machine on Centos 7 kvm/qemu/libvirt stack.
Two hardware NICs presented to VM as libvirt devices. Switching the device to e1000 or rtl emulation doesn't change the outcome.
WAN 66.55.55.44 gw 66.55.55.43 Gateway test of a dns query passes.
LAN 192.168.1.1
Time on the host is accurate.When VM is up, I can ping 192.168.1.1. I can telnet 192.168.1.1 443. I cannot establish an SSL session of any kind. I've tried installer versions 2.4.3 and 2.4.2 and have the identical issue.
At this moment, I've downgraded to 2.3.3 and the ssl web GUI work as expected.
I can spin up another 2.4.x if it helps. It won't change anything.
-
Perhaps a clue, but I noticed last week that I could no longer log into my vSphere web ui in Firefox. It still worked in Chrome, but FF told me that there was a problem with the cert auth and no exception could be created.
-
so your changing the IP.. Are you generating a new cert for use with the https after you change the IP?
Your browser is going scream at you if info the cert doesn't match..
What browser are you using?
-
@KOM:
Perhaps a clue, but I noticed last week that I could no longer log into my vSphere web ui in Firefox. It still worked in Chrome, but FF told me that there was a problem with the cert auth and no exception could be created.
Doesn't work on Linux or Windows with Chrome and Firefox on both platforms.
