How does a receiver treat X.509 self-certificate with unknown the Signature Algorithm ID? As I know X.509 self-certificate is a mechanism that the host generates public and private keys, the public key will insert to a certification and the private key will be used to sign the certification. The receiver will verify the certificate by using the public key with certification. 

In case if the receiver does not have the algorithm that used to sign the certification, how the receiver can verify the certification?

Does X.509 has default algorithm to sign the certification?
In the latest X.509 RFC you can read:


  The signatureAlgorithm field contains the identifier for the
     cryptographic algorithm used by the CA to sign this certificate.
     [RFC3279], [RFC4055], and [RFC4491] list supported signature
     algorithms, but other signature algorithms MAY also be supported.


However from RFC 3279, section 2:


  Conforming CAs and applications MUST, at a minimum, support digital
     signatures and public keys for one of the specified algorithms.  When
     using any of the algorithms identified in this specification,
     conforming CAs and applications MUST support them as described.


But more importantly, when verifying a certificate chain, there is no need to perform the validation certificate when validating the certificate chain. This certificate needs to be trusted beforehand.

So if you receive the certificate by the appropriate "out-of-band" procedure, you could validate the certificate at that time. Afterwards you only need to validate the dynamic values such as the end date of the certificate and - possibly - the status of the certificate - if it has been revoked or not.

That means that for devices with limited capacity you can validate and verify the certificate beforehand, put it in the device using a trusted path to the device / storage and then "just" check the date in the field.

This can be read in section 6.1 of the X.509 RFC:


  When the trust anchor is provided in the form of a self-signed
     certificate, this self-signed certificate is not included as part of
     the prospective certification path.  Information about trust anchors
     is provided as inputs to the certification path validation algorithm
     (Section 6.1.1).




Great, so that solves the problem, right? Not really. The public key of the certificate is commonly also used to encrypt or to verify the signatures send in the application - the reason the certificate exists in the first place. So now you've got your trusted "chain" of one certificate you're stuck with a public key that you cannot use, because it is identical to the one performing the signature verification over the certificate itself.

It would of course be possible that the receiver can encrypt or perform key agreement using the public key while the signature verification algorithm isn't available.

This issue is specific to self signed certificates because the public key is generally only used for a single purpose, while it must at least sign and possibly perform another kind of operation as well.



Notes:


Protocols may put additional requirements on which algorithms are supported, e.g. although TLS doesn't explicitly require RSA signatures / encryption, many websites would not work without it.
"a certificate" has a different meaning than "a certification". The latter means having a product certified against e.g. FIPS or Common Criteria. So "certification" is normally used in the more analog, paper-y sense.
"just" is put within quotation marks because getting the time from a trusted time source may be very tricky on restricted devices.