Get all certificates and their virtual servers and SSL profiles via API calls
Problem this snippet solves: Summary F5 will give you a decent report of all your certificates and their expiration dates. However I have not found a way to pull what Virtual Server or SSL Profile the certificates are applied to (or if they are used at all). What this code does is grabs all the virtual servers, all SSL profiles, and all certificates. Then it loops through them to find where a certificate is applied. Then it returns the certificate and virtual server info. I wrote this in C# but the logic can be used anywhere as the API calls are independent of language. How to use this snippet: You will need some way to compile C#. Easiest way is to use Visual Studio. Simply add your API credentials and IP addresses and run the code through a C# compiler. Code : https://github.com/matthewwedlow/F5_Scripts/blob/master/GetCerts.cs
An invalid or expired certificate was presented by the server
Hi Guys! So we are building a per-app VPN setup using Intune för iOS (iPADOS) units and we pushed out F5 Access app along with Intune F5 Access App which is then configured using F5 Access VPN profile using authentication with certificate which is pushed out to the device from internal CA using connector. Certificates for device is installed fine along side with root and intermediate, the profile in F5 Access app has all the settings correct and the certificate is listed. On server side we also configured everything with access policy for iOS, we have added certificate for root and intermediate for trust and everything looks as it should but we seem to have missed something and are unable to initiate a VPN connection, the device attempts to start a VPN tunnel but failes to do so with error " An invalid or expired certificate was presented by the server" What are we missing? Something with the ceritficates? a setting on device? something on server we missed adding the trust? 2021-05-11,15:36:54:112, 537,21259[com.apple.NSXPCConnection.user.endpoint],PacketTunnel, 48, PacketTunnelProvider.swift:435, startTunnel(options:completionHandler:), ------------------------------------------------------------ 2021-05-11,15:36:54:112, 537,21259[com.apple.NSXPCConnection.user.endpoint],PacketTunnel, 48, PacketTunnelProvider.swift:436, startTunnel(options:completionHandler:), Release Version: 3.0.7 2021-05-11,15:36:54:112, 537,21259[com.apple.NSXPCConnection.user.endpoint],PacketTunnel, 48, PacketTunnelProvider.swift:437, startTunnel(options:completionHandler:), Bundle Version: 3.0.7.402 2021-05-11,15:36:54:113, 537,21259[com.apple.NSXPCConnection.user.endpoint],PacketTunnel, 48, PacketTunnelProvider.swift:438, startTunnel(options:completionHandler:), Build Date: Mon Sep 9 12:13:19 PDT 2019 2021-05-11,15:36:54:113, 537,21259[com.apple.NSXPCConnection.user.endpoint],PacketTunnel, 48, PacketTunnelProvider.swift:439, startTunnel(options:completionHandler:), Build Type: CM 2021-05-11,15:36:54:113, 537,21259[com.apple.NSXPCConnection.user.endpoint],PacketTunnel, 48, PacketTunnelProvider.swift:440, startTunnel(options:completionHandler:), Changelist: 3134102 2021-05-11,15:36:54:114, 537,21259[com.apple.NSXPCConnection.user.endpoint],PacketTunnel, 48, PacketTunnelProvider.swift:441, startTunnel(options:completionHandler:), Locale: English (Sweden) 2021-05-11,15:36:54:114, 537,21259[com.apple.NSXPCConnection.user.endpoint],PacketTunnel, 48, PacketTunnelProvider.swift:442, startTunnel(options:completionHandler:), ------------------------------------------------------------ 2021-05-11,15:36:54:117, 537,21259[com.apple.NSXPCConnection.user.endpoint],PacketTunnel, 48, PacketTunnelProvider.swift:451, startTunnel(options:completionHandler:), Connection Parameters: Optional("serverAddress: https://ourserver.adress.com, password: , ignorePassword: false, passwordExpirationTimeStamp: -1, passwordReference: not-set, passwordExpired: false, identityReference: set, postLaunchUrl: , webLogon: false, launchedByUriScheme: false, vpnScope: device, startType: manual, deviceIdentity: assignedId: ,instanceId: ,udid: ,macAddress: ,serialNumber: ") 2021-05-11,15:36:54:229, 537,21259[com.apple.NSURLSession-delegate],PacketTunnel, 1, AsyncURLRequest.swift:186, urlSession(_:didReceive:completionHandler:), Server certificate can not be trusted. 2021-05-11,15:36:54:233, 537,21259[com.apple.NSURLSession-delegate],PacketTunnel, 1, ProfileDownloadOperation.swift:94, main(), Profile download failed: sslInvalidServerCertificate 2021-05-11,15:36:54:236, 537,10507[com.apple.root.default-qos],PacketTunnel, 1, SessionManager.swift:127, logon(connectionParams:completionHandler:), Failed to download Profile Settings...Error:sslInvalidServerCertificate 2021-05-11,15:36:54:237, 537,10507[com.apple.root.default-qos],PacketTunnel, 1, PacketTunnelProvider.swift:527, startTunnel(options:completionHandler:), Failed to logon Error Domain=f5PacketTunnelProvider Code=0 "An invalid or expired certificate was presented by the server" UserInfo={NSLocalizedFailureReason=Error Domain=PacketTunnel.AsyncURLRequestError Code=5 "An invalid or expired certificate was presented by the server", NSLocalizedDescription=An invalid or expired certificate was presented by the server} 2021-05-11,15:36:54:238, 537,10507[com.apple.root.default-qos],PacketTunnel, 1, PacketTunnelProvider.swift:383, displayMessageIfUIVisible, An invalid or expired certificate was presented by the server Any thoughts be much appreciated! Thanks in advance Alex
Windows BIG-IP Edge Client cannot verify certificate revocation information
Hi, I have the local Windows firewall on for my test machine ONLY allows access to the IP address of the SSL VPN. This all works fine. However the Windows BIG-IP Edge Client cannot verify certificate revocation information. The funny thing is, Internet Explorer can and doesnt give me any warnings. I've tried making it a trusted site, installing the certificate. I just don't know why IE can check it/trust it, but the Edge Client can't?Create a CSR and Key using the BigIP LTM GUI when renewing a certificate
Hi, I use the F5 Bigip LTM to create CSR's and Keys. I submit the CSR to our public CA to obtain the Certificate and then import the generated certificate to the F5. I use the F5 Certificate Management GUI as a database for all of our Public Certificates (as they are all in use in our SSL profiles). All this is good, however after 13 months when it is time to renew the certificate, I use the F5 GUI to renew the CSR. The problem is that the GUI does not allow me to create a new key when using the "Renew" option. I could use other command line tools for this, but it would be easier to manage in the F5 GUI. Does anyone know if there is a way to renew a certificate from the F5 GUI and have it create a new Key? For example click on "System / Certificate Management". Then click on a Public CA Certificate and click "Renew". Fill out the required fields and have it generate a new key. Any advice is appreciated.
Post of the Week: SSL on a Virtual Server
In this Lightboard Post of the Week, I answer a few questions about SSL/https on Virtual Servers. BIG-IP being a default deny, full proxy device, it's important to configure specific ports, like 443, to accept https traffic along with client and server side profiles and include your SSL certificates. We cover things like SAN certificates but I failed to mention that self-signed certificates are bad anywhere except for testing or on the server side of the connection. Thanks to DevCentral members, testimony, Only1masterblaster, Faruk AYDIN, MrPlastic, Tyler G, Prince, and dward for their Q/A engagement. Posted Questions on DevCentral: https on virtual server LINKING SSL CERTIFICATE TO A VIRTUAL SERVER SSL CERTIFICATE KEY Maximum number of client SSL profiles per virtual server? Need to support thousands of unique SSL certificates on a single VIP ps
Beware Using Internal Encryption as an IT Security Blanket
It certainly sounds reasonable: networks are moving toward a perimeter-less model so the line between internal and external network is blurring. The introduction of cloud computing as overdraft protection (cloud-bursting) further blurs that perimeter such that it’s more a suggestion than a rule. That makes the idea of encrypting everything whether it’s on the internal or external network seem to be a reasonable one. Or does it? THE IMPACT ON OPERATIONS A recent post posits that PCI Standard or Not, Encrypting Internal Network Traffic is a Good Thing. The arguments are valid, but there is a catch (there’s always a catch). Consider this nugget from the article: Bottom line is everyone with confidential data to protect should enable encryption on all internal networks with access to that data. In addition, layer 2 security features should be enabled on the access switches carrying said data. Be sure to unencrypt your data streams before sending them to IPS, DLP, and other deep packet inspection devices. This is easy to say but in many cases harder to implement in practice. If you run into any issues feel free to post them here. I realize this is a controversial topic for security geeks (like myself) but given recent PCI breaches that took advantage of the above weaknesses, I have to error on the side of security. Sure more security doesn’t always mean better security, but smarter security always equals better security, which I believe is the case here. [emphasis added] It is the reminder to decrypt data streams before sending them to IPS, DLP, and other “deep packet inspection devices” that brings to light one of the issues with such a decision: complexity of operations and management. It isn’t just the additional latency inherent in the decryption of secured data streams required for a large number of the devices in an architecture to perform their tasks that’s the problem, though that is certainly a concern. The larger problem is the operational inefficiency that comes from the decryption of secured data at multiple points in the architecture. See there’s this little thing called “keys” that have to be shared with every device in the data center that will decrypt data, and that means managing each of those key stores in their own right. Keys are the, well, key to the kingdom of data encryption and if they are lost or stolen it can be disastrous to the security of all affected systems and applications. By better securing data in flight through encryption of all data on the internal network an additional layer of insecurity is introduced that must be managed. But let’s pretend this additional security issue doesn’t exist, that all systems on which these keys are stored are secure (ha!). Operations must still (a) configure every inline device to decrypt and re-encrypt the data stream and (b) manage the keys/certificates on every inline device. That’s in addition to managing the keys/certificates on every endpoint for which data is destined. There’s also the possibility that intermediate devices for which data will be decrypted before receiving – often implemented using spanned/mirrored ports on a switch/router – will require a re-architecting of the network in order to implement such an architecture. Not only must each device be configured to decrypt and re-encrypt data streams, it must be configured to do so for every application that utilizes encryption on the internal network. For an organization with only one or two applications this might not be so onerous a task, but for organizations that may be using multiple applications, domains, and thus keys/certificates, the task of deploying all those keys/certificates and configuring each device and then managing them through the application lifecycle can certainly be a time-consuming process. This isn’t a linear mathematics problem, it’s exponential. For every key or certificate added the cost of managing that information increases by the number of devices that must be in possession of that key/certificate. INTERNAL ENCRYPTION CAN HIDE REAL SECURITY ISSUES The real problem, as evinced by recent breaches of payment card processing vendors like Heartland Systems is not that data was or was not encrypted on the internal network, but that the systems through which that data was flowing were not secured. Attackers gained access through the systems, the ones we are pretending are secure for the sake of argument. Obviously, pretending they are secure is not a wise course of action. One cannot capture and sniff out unsecured data on an internal network without first being on the internal network. This is a very important point so let me say it again: One cannot capture and sniff out unsecured data on an internal network without first being on the internal network. It would seem, then, that the larger issue here is the security of the systems and devices through which sensitive data must travel and that encryption is really just a means of last resort for data traversing the internal network. Internal encryption is often a band-aid which often merely covers up the real problem of insecure systems and poorly implemented security policies. Granted, in many industries internal encryption is a requirement and must be utilized, but those industries also accept and grant IT the understanding that costs will be higher in order to implement such an architecture. The additional costs are built into the business model already. That’s not necessarily true for most organizations where operational efficiency is now just as high a priority as any other IT initiative. The implementation of encryption on internal networks can also lead to a false sense of security. It is important to remember that encrypted tainted data is still tainted data; it is merely hidden from security systems which are passive in nature unless the network is architected (or re-architected) such that the data is decrypted before being channeled through the solutions. Encryption hides data from prying eyes, it does nothing to ensure the legitimacy of the data. Simply initiating a policy of “all data on all networks must be secured via encryption” does not make an organization more secure and in fact it may lead to a less secure organization as it becomes more difficult and costly to implement security solutions designed to dig deeper into the data and ensure it is legitimate traffic free of taint or malicious intent. Bottom line is everyone with confidential data to protect should enable encryption on all internal networks with access to that data. The “bottom line” is everyone with confidential data to protect – which is just about every IT organization out there – needs to understand the ramifications of enabling encryption across the internal network both technically and from a cost/management perspective. Encryption of data on internal networks is not a bad thing to do at all but it is also not a panacea. The benefits of implementing internal encryption need to be weighed against the costs and balanced with risk and not simply tossed blithely over the network like a security blanket. PCI Standard or Not, Encrypting Internal Network Traffic is a Good Thing The Real Meaning of Cloud Security Revealed The Unpossible Task of Eliminating Risk Damned if you do, damned if you don't The IT Security Flowchart
