ASDM Package Is Not Digitally Signed Rejecting Configuration | Quick Fix Steps

When this message appears on a Cisco ASA, the box is telling you that the graphical manager on flash no longer passes the new image checks. The firewall still passes traffic, yet you lose the simple ASDM window that many teams rely on for everyday work.

This change comes from recent security hardening on the ASA and ASDM side. Older images stayed on many devices for years, so the moment you upgrade ASA code you may suddenly see the warning and lose the launcher. The good news is that the fix to this configuration rejection is very direct once you understand what the message really means.

What The “ASDM Package Is Not Digitally Signed Rejecting Configuration” Error Means

Newer ASA trains verify that the ASDM image on flash carries a Cisco digital signature. The check runs when you enter the asdm image command and when the device boots. If the image does not pass the signature check, ASA prints % ERROR: ASDM package is not digitally signed. Rejecting configuration. and ignores that line in the running configuration.

In practice, this leaves you with a working firewall that no longer launches ASDM, because the software image on disk0 does not meet the new requirement. The phrase rejecting configuration describes that ASA drops the asdm image setting instead of loading the unsigned file.

Cisco added this validation after research showed that unsigned ASDM packages could open a path for tampering. The fix landed in recent ASA maintenance releases together with new ASDM versions that ship with a digital signature. Those newer launchers work with older ASA releases as well, so once you move to a signed image you are in a better place for long term use.

Asdm Package Is Not Digitally Signed Error On New Asa Builds

Most administrators meet the message right after an ASA upgrade. The upgrade path often keeps the old ASDM file in flash while you move the firewall image to a current release. After the reboot, the ASA validates the ASDM file, finds that the image has no signature, and rejects the configuration that points to it.

You might notice clues like ASDM no longer launching from the browser portal, or the launcher popping a warning and failing to connect. When you log in to the CLI and run show running-config asdm, you either see no asdm image line at all or you see the error every time you try to apply the command. The message asdm package is not digitally signed rejecting configuration is the ASA way of telling you that only signed ASDM images are accepted from this point onward.

This behavior is by design on newer ASA versions and on Secure Firewall 3100 appliances. The device protects both the firewall and the admin workstation from tampered GUI packages. Your task is to replace the stale image with a current one that includes Cisco’s digital signature.

Fixing The ASDM Package Not Digitally Signed Error Step By Step

Work through these checks and actions in order so you can restore ASDM without guesswork.

1. Confirm The Asa Version — Run show version and note the ASA release and model. Newer trains such as 9.18 and later always enforce signed ASDM images, while midrange builds on Secure Firewall 3100 hardware add extra checks.
2. Check The Current ASDM Image — Run show disk0: or show flash: to see which ASDM files sit on the device. Typical names look like asdm-7.17.bin or asdm-openjre-7.18-1-152.bin. Older minor releases usually lack a digital signature.
3. Inspect The Running Configuration — Use show running-config asdm. If you only see asdm history enable with no asdm image line, ASA has already dropped the previous setting. If the line is there, try reentering it in configuration mode to see whether the error appears again.
4. Download A Signed ASDM Release — From Cisco’s software download center, obtain a current ASDM image that matches Cisco’s recommended matrix for your ASA code. Releases such as 7.18(1.152) and newer include a digital signature and stay compatible with older ASA versions as well.
5. Copy The Image To Flash — Place the file on a TFTP, FTP, or HTTP server and run a copy command like copy tftp: disk0:. Pick a simple filename and confirm the transfer with show disk0: once the copy completes.
6. Point ASA To The New Image — Enter configuration mode and run asdm image disk0:/your-asdm-file.bin. If the image is signed, the command should accept without the digital signature error. Save the change with write memory.
7. Reload If ASDM Still Fails — In many cases ASDM starts working as soon as you set the new image. If the launcher keeps failing, schedule a reload so the ASA boots cleanly with the new ASDM file and HTTPS stack.
8. Check For Known Platform Bugs — On Secure Firewall 3100 appliances, certain ASA builds raised a false verification error even for signed images. Cisco released fixes for those trains, so if the message persists you may need an ASA upgrade to a fixed release.

Once the ASA accepts the new asdm image line and the launcher connects, the asdm package is not digitally signed rejecting configuration message should disappear from the console. At that point you can remove any very old ASDM files from flash to keep the storage tidy.

Checking Asa And ASDM Version Compatibility

Before you settle on one ASDM file, it pays to match it with your ASA train. Cisco publishes a matrix that lists recommended combinations of ASA and ASDM releases. Aligning with that chart removes many small annoyances such as missing menu items or Java misbehavior.

Use these checks when you pick the final ASDM image.

• Verify The Recommended Pairing — Look up the table for your ASA major release and pick the ASDM line that Cisco flags as preferred. That reduces the chance of new bugs or missing features on your firewall model.
• Keep To One ASDM Train — Try not to mix many different ASDM files across your fleet. A single current train such as 7.18 for all ASA versions keeps testing and admin habits simpler.
• Match Java Requirements — Some ASDM images ship with an embedded Java runtime, while others expect a local Java install. Pick the option that fits your desktop standard to avoid launch hiccups.
• Allow Enough Flash Space — Signed ASDM images can be larger than old files. Confirm that flash still has room for ASA code, ASDM, AnyConnect packages, and logs before and after the copy.

When your ASA and ASDM versions line up with the published matrix, you not only clear the digital signature error but also reduce random launch problems later on.

Extra Checks When ASDM Still Refuses To Launch

Sometimes the digital signature warning hides behind other small issues. After you replace the image, still walk through a short round of service checks so you do not blame the signature check for an unrelated problem.

• Confirm HTTPS Access — Run show running-config http and make sure your management subnet or host has permission. Without that line, ASDM cannot reach the ASA even when the image is valid.
• Review TLS Settings — Recent browsers and Java builds refuse weak ciphers. Use show running-config ssl to see which ciphers and versions your ASA offers, and align them with current browser expectations.
• Test With The ASDM Launcher — If you normally start ASDM from a browser link on the ASA, try the standalone launcher as well. Launch failures from Java Web Start or older browser plugins do not always relate to the ASDM image on flash.
• Check Local Firewalls On The Admin Pc — Host firewalls and endpoint tools sometimes block the ASDM port or the Java process. Temporarily relax those rules for a quick test, then tune them to allow regular ASDM sessions.
• Watch The Asa Logs During Launch — Use terminal monitor or a syslog server and trigger an ASDM login. Fresh messages about SSL negotiation, HTTP access, or user login attempts help separate image issues from network or policy issues.

If all of these checks pass and the signed ASDM file still triggers errors, capture the output from show tech and open a case with Cisco so they can match your platform and code against current defects.

Reference Table For ASDM Signature Related Messages

This compact table gives you a quick map from common ASDM signature messages to likely causes and fast fixes. You can keep it beside your change notes during ASA upgrades.

Error Text	Typical Cause	Go-To Fix
% ERROR: ASDM package is not digitally signed. Rejecting configuration.	ASA now enforces signed ASDM images and the configured file on flash lacks a Cisco signature.	Load a current signed ASDM release, set the asdm image line to that file, and save.
% ERROR: Signature not valid for file disk0:/	File is damaged, tampered, or built for another platform, so the signature check fails.	Redownload the ASDM file from Cisco, recopy it to flash, and point the ASA to the fresh image.
ASDM cannot be loaded. Click for more information.	Browser, Java, or TLS settings prevent the launcher from completing the session.	Use the standalone launcher, align SSL settings, and confirm desktop Java and access rules.

With these patterns in mind, you can tell at a glance whether you are facing a digital signature issue, file damage, or a plain launch problem on the admin workstation.

Maintenance Habits That Prevent The Error Next Time

Once you clear today’s fault, treat it as a reminder to tidy your ASA maintenance routine. Signed ASDM images move forward with each release, so a short review plan keeps surprises away when you next touch firewall code.

• Bundle ASA And ASDM Upgrades — When you schedule an ASA upgrade, always stage a matching signed ASDM image on flash during the same window.
• Prune Old Files Regularly — After each change, remove retired images and unused AnyConnect packages so only known good files stay on the device.
• Record Working Version Pairs — Note down stable ASA and ASDM pairs in your change log so you can repeat a proven combo on other appliances.

Teams that track these small habits see far fewer surprises from image checks, whether the change comes from a planned upgrade or from a code train that shipped with stricter validation toggled on by default. That pattern also shortens the time to sort out later ASDM launch problems during a busy outage call. That little detail saves time during tense fault calls.